[ILUG] bloody redhat!!

[kevin lyda]

Paul Jakma wrote:
> I was reffering more to X apps in general. I guess the FHS specifies
> that non X11R6 stuff should be in /usr/bin, but that is not
> "right". Have a look at /usr/bin, the directory alone is 20480 in
> size on my system!! And it's packed full of a mish mash of stuff.
> 
> IMO the "Right" way is that distinct classes of bin's should go in
> seperate dir's, eg KDE/GNOME/misc X11 should each have their own bin
> dir.

http://www.pathname.com/fhs/2.0/fhs-4.3.html

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.

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?  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?)

> I'll check it out. /usr/bin on RH6.1 is insane.

how should it be designed?  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.  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 - 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.

namespaces are fun, eh?

> i'm not sure of the exact evolution, but in any case nenscripts is
> gone and now replaced with the most abhorrent filter scripts. have a
> look.

yes, nenscript is gone, replaced by enscript.  however rhs-printfilters
required neither, this is a query on the 4.2 version of them:

rpm -qRp /mnt/cdrom/RedHat/RPMS/rhs-printfilters-1.41-1.i386.rpm
libc.so.5  
ghostscript >= 3.33
lpr >= 0.17
mpage >= 2.4

they use mpage to do ps manipulation, and still do.  i use enscript as
well - i have a program that i use to list code that spews to enscript. 
and i use it in combination with the rhs filters.

> they're not bugs per se. they are a result of design decisions RH has
> made.

to follow the fhs - and not extend it.  i'm more upset when they don't
follow it.  so perhaps joining the fhs mailing list you'll effect the
change you want.

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
-- 
kevin at suberic.net                              Nutrition Facts
fork()'ed on 37058400		       Puns: 100% RDA  (% good puns: 0)