[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


Reply to: