Charles Plessy <ple...@debian.org> writes:
> How about something among these lines:
> - A Blend provides a directory /usr/share/<name-of-the-blend>.
> - Packages can add symlinks there on a voluntary basis.
> - The blend installs a script in /etc/profile.d, that adds the
> symlinks directory to the PATH of the users that are in the
> Blend's unix group.
> This requires coordination between package maintainers and blends
> maintainers, but in the case we are discussing, they are often the same
> persons or part of the same team.
> This will not work in all cases, but I think that the focus here is ‘out
> of the box’ usage, by persons who usually do not modify their PATH.
My primary concern in this area is that whatever we do still follow the
dictates (and spirit) of Policy 9.9:
A program must not depend on environment variables to get reasonable
defaults. (That's because these environment variables would have to be
set in a system-wide configuration file like /etc/profile, which is
not supported by all shells.)
If a program usually depends on environment variables for its
configuration, the program should be changed to fall back to a
reasonable default configuration if these environment variables are
not present. If this cannot be done easily (e.g., if the source code
of a non-free program is not available), the program must be replaced
by a small "wrapper" shell script which sets the environment variables
if they are not already defined, and calls the original program.
I think those of us who have been administering UNIX systems for a while
remember all the pain caused by mh and its desire to use very generic
command names in a different directory that users added to their PATH, and
all the weirdness that resulted, and don't want to go back to that world.
The (very happy) trend recently has been towards having large packages
with lots of separate commands reserve a single command name and then give
their commands as subcommands. See, for example, git, which no longer
provides all the git-* commands on the user's PATH. This is the approach
that I think we should advocate with upstream. It makes management of the
namespace much easier, and avoids having to play with a user's PATH.
Please remember that setting the system-wide default PATH to support some
applications installed on that system often makes no sense. Timeshare
systems shared by many different people doing many different things are
still quite common, including in batch computing environments. Only the
people who care about a particular piece of software may want their set of
commands to include all those generic commands from some piece of
software. Also remember that this doesn't solve the problem of two
packages that both want to provide the same generic name.
Similar to conflicting library names, it's important to realize that
moving one binary to a different location and adding it to the PATH does
*not* resolve the conflict. It just masks one binary with the other, in a
way that can now be somewhat non-deterministic and even more confusing.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739uioxes....@windlord.stanford.edu
