[Radiance-dev] Re: Radiance in Debian
Bernd Zeimetz
bernd at bzed.de
Mon Nov 5 17:24:40 PST 2007
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
--
Bernd Zeimetz
<bernd at bzed.de> <http://bzed.de/>
More information about the Radiance-dev
mailing list