From: Paul Jakma (paul at domain clubi.ie)
Date: Sun 13 Feb 2000 - 15:20:48 GMT
On Sat, 12 Feb 2000, kevin lyda wrote:
the fhs makes no mention of other sub directories outside of mh and
X11. yes, kde and gnome dirs would be good, but beware going too far
otherwise people will get all antsy about their PATH vars. i've seen
several discussions (mainly bsd folks) bitching about the PATH expanding
design of /opt.
/opt is bad anyway. :) Going too far is bad too, i would be similarly
disgusted by a Windows style namespace where every package had it's
own bin dir. But Gnome and KDE are two very abstract collections
that should be given their own dir's on linux.
My preference would also be to keep other X11 apps seperate from
/usr/bin. They are another distinct class of apps on Linux.
it's a design issue with unix in general i'm afraid. it's mainly
exposed by redhat, but all free software with it's huge number of apps
has this issue: where do they go, and how do you get at them?
PATH. I would prefer one or two extra additions to PATH than a 24kb
directory of bin's. From a performance point of view, several 4/8kb
dir with apps are preferable to one huge dir.
PATH should be set up to grock globs: /usr/bin:/usr/*/bin:/opt/*/bin ?
(gee, that'll break a few million shell scripts - maybe a GLOBPATH?)
> I'll check it out. /usr/bin on RH6.1 is insane.
how should it be designed?
through loads of arguing? :) seriously though, it's very
subjective. it's sugar to one, salt to another.
gnome is producing apps as if the project
actually *did* have an infinite number of monkeys working for it. so
/usr/gnome won't work for long.
but at least they won't be crowding /usr/bin. And i don't have to
have gnome/kde/X11 dirs in my PATH when at console.
then you'll want /usr/kde. the former
netpbm, now libgr-progs, contributes 178 binaries, so maybe a
/usr/graphics? and then there's mh (nmh seems to make /usr/bin/mh a
soft link to /usr/bin and then puts all it's bins in /usr/bin. that's
that is. Although i do agree with the concept of private binaries. Ie
binaries that a package requires, but are not meant to be run by the
user. -> /usr/lib/package/
- and that *does* appear to be a redhat decision:
/usr will have hundreds of directories, and a PATH var will fill the
that wouldn't be good.
namespaces are fun, eh?
lots of fun. Namely people never agree, so you end up with the worst
of all worlds -> 24kb /usr/bin. :)
to follow the fhs - and not extend it. i'm more upset when they don't
apparently plan 9 does a lot of work to deal with namespace issues.
perhaps the free unix community will work to follow their lead (though
i'm not too sure what it is, or if it's much better).
-- Paul Jakma paul at domain clubi.ie PGP5 key: http://www.clubi.ie/jakma/publickey.txt ------------------------------------------- Fortune: The optimum committee has no members. -- Norman Augustine
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:05:25 GMT