[ILUG] bloody redhat!!

[Paul Jakma]

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.

  perhaps
  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?)
  
yuk.

  > 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
  just goofy

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:
  http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9384).  eventually
  /usr will have hundreds of directories, and a PATH var will fill the
  screen.
  
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
  follow it.  

agreed.

  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).
  
  kevin
  
regards,
-- 
Paul Jakma	paul at clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
The optimum committee has no members.
		-- Norman Augustine