[ILUG] bloody redhat!!

[Lars Hecking]

> 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 truely sucks. And I'm really a fan of Solaris :)

 Ok, you make /opt a truely shared fs just like /usr/local under BSD.
 Fine. Just the same.

 But then you have another package going into /opt on _your_ machine,
 for _this_ hardware and _this_ version of the OS.

 Fsck. So you go back to per-machine /opt PLUS /usr/local for all other
 progs that can be shared.

 This is why /opt sucks. Sorry, do I repeat myself?

> 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?)
 
 Has anyone ever had a closer look at GNU stow? Could it be the
 salvation we all have been looking for?

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

 Interesting. Could you give us (me, mainly :) more details about what netpbm
 has grown into?

> /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:

 I only discovered enscript a few months ago, and it's really neat.
 Will go ahead and convert existing scripts to enscript over time.

> 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).
 
 Haven't looked at plan9 in ages ...