[Radiance-dev] Re: Radiance in Debian

[Jack de Valpine]

Sorry, I meant genbox not xform in the first sentence!

Jack de Valpine wrote:
> 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
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Radiance-dev mailing list
> Radiance-dev at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-dev
>   

-- 
# 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/ad459a45/attachment.html