Re: netpbm vs. pbmplus
Chris Fearnley writes ("Re: netpbm vs. pbmplus"):
> But /usr/bin/mh already exists and has 32 files in it. The mh case is
> explicitly mentioned in FSSTND. I like it because, I like to ls in
> /usr/bin/{mh,netbm} to try to find which program I need. Perhaps the
> postinst should warn that the programs aren't included in the default
> PATH?
There is a good reason for mh not to be included in the path by
default - its commands are very short and likely to clash with other
programs, do not have a particular form which makes it clear that
they're part of mh, and they can do confusing things (like eating the
user's mail and putting it in a directory they don't know about) if
invoked by mistake.
netpbm *definitely* wants to be on the default path.
> My opinion is any package with > ~20 files in /usr/bin should create a
> subdirectory of /usr/bin.
This is not the way we have done things up til now, and I don't think
now is the time to start. If you want to discuss the merits of
putting shellutils, fileutils, git, &c &c &c into separate directories
I suggest we don't do it on debian-devel.
Mark W. Eichin writes ("Re: netpbm vs. pbmplus"):
> [...] kerberos provides programs named rlogin, rsh, rcp, ftp,
> telnet [...]. *however* in the case of rlogin,
> rsh, and rcp, if the kerberos one fails, it falls back to actually
> running the "native" version.
>
> In general, we've just done the equivalent of a prefix=/usr/kerberos
> and that has worked fine, but seems to be counter to what is dicussed
> here. I suppose that exec-prefix=/usr/bin/kerberos prefix=/usr is
> about right?
That's more or less what I'd suggest, yes. I suppose that
--program-prefix=k (which I've seen in some places) has the
disadvantage that every command is now called something different ...
> At MIT, users can select packages using "add package", which does roughly
> * mounts the package [usually on /mit/package]
> * adds $mountpoint/arch/$sys/bin to the user's path
> This is not unlike the svr4 use of /opt/package, though I haven't seen
> standardized convenience aliases (every sysadmin and half the users
> write their own :-) I suppose these mechanisms don't fit in either?
In my experience these schemes are very difficult to implement well -
I've never seen it successfully done. They tend to interfere with the
usual ways sysadmins and users like to set the path &c, and need
rewriting for every shell.
Ian.
Reply to: