[Radiance-dev] Re: Radiance in Debian

[Jack de Valpine]

Hi Bernd,

I was just poking around a bit and I wonder about using 
/etc/alternatives to manage the conflict between the two versions of 
xform? So perhaps there could be /usr/bin/rgenbox for radiance and 
/usr/bin/ggenbox for gromacs which then get resolved by 
/etc/alternatives/genbox? This /etc/alternatives is new to me so I am 
not clear if I am thinking about this the right way.

-Jack de Valpine

Bernd Zeimetz wrote:
> Hi Greg,
>
>   
>> This e-mail must have caught you at a bad time 
>>     
>
> Not a too bad time, but I'm a kinda annoyed by people who suggest to
> make the use of software more complicated for the common user because
> they know all about it. I'm sorry for the rant.
>
>   
>> separate directory as Schorsch suggests, similar to /usr/X11R6/bin and
>>     
>
> This was removed for a good reason.
> For compatibility /usr/bin/X11 is a link to /usr/bin, and /usr/X11R6/bin
> is a link to /usr/bin, too.
>
>   
>> I don't think you want to
>> receive complaints about crowding /usr/bin and causing name conflicts
>> any more than I do.
>>     
>
> Definitely not, I'm more than interested to hear opinions about the way
> to handle this, too. Although I'd just keep it as it is for the moment -
> the chance that we have a name clash before Lenny is pretty low imho.
> Also in most cases I have the better arguments (use in
> clusters/scripts/existing stuff/....) - but not against a suite which
> works similar to radiance, is in Debian since a _long_ time and has >
> 280 popcon reports. Although their maintainer offered to rename it, it
> didn't take long until the first users yelled at him. It is only sane to
> leave genbox to them. gromacs ships with 85 files in /usr/bin for
> example - so having 123 files in /usr/bin is not a problem, definitely.
>
> If you look at the popcon stats, radiance is rising more and more and I
> hope this keeps going, so we have a good argument not to rename anything.
>
> The other problem which would be introduced by moving stuff away would
> be the manpages, they couldn't be installed into section 1 anymore, so
> this would be extra work to change the section and move them accordingly.
>
> The only way I can see is if we're able to distinguish between programs
> which are used by other programs only, and not by user _scripts_ (as in
> csh/bash/..., which relies on $PATH), they could be installed in a
> different directory. Installing tools, which are used by a normal user,
> into a different directory then /usr/bin would be a violation of the FHS.
>
>   
>> As for naming all future Radiance programs rad-this or rad-that, it just
>> isn't going to happen.
>>     
>
> No need to call them rad-foo, but for example instead of cv call a
> program metacv or metaconv. This rises the chance that somebody else
> uses a different name. For example brl-cad ships a cv binary, too, and
> looking at http://lists.debian.org/debian-changes/2000/01/msg00006.html
> it seems we had a /usr/bin/cv some long time ago in the xa+cv package.
> Also googling for /usr/bin/intendedprogramname helps.
>
> I still think even if we'd have to rename another tool (I'll try to
> avoid that, bu you can't know) everybody who doesn't want to follow such
> a name change is able to use the suggested compat directory. Adding
> something to PATH in general or adding it only if you want to use the
> original names doesn't make a bit difference imho. Please note that I
> can't add directories to $PATH automatically, it's always something that
> needs to be done by the user/admin.
>
>   
>> Renaming everything in a go would cause dozens of compatibility issues
>> like the genbox problem we've discussed ad nauseam, so I don't really
>> see this as a viable solution.
>>     
>
> No, renaming all tools doesn't make any sens at all and I'd never
> suggest that.
>
>   
>> Is it possible to offer a different installation directory at least as
>> an option?
>>     
>
> Not if you use packages.
>
> Best regards,
>
> Bernd
>   

-- 
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://radiance-online.org/pipermail/radiance-dev/attachments/20071105/808cb698/attachment-0001.htm