On Tue, Dec 04, 2001 at 04:02:13PM -0500, Paul Lussier wrote: > > In a message dated: Tue, 04 Dec 2001 15:26:11 EST > Paul Iadonisi said: > > > I normally don't speak up either, but I'm of the same mind as Red Hat. > >To be blunt, as a sysadmin, I despise the concept of throwing *all* of a > >packages files under a single directory. > > Well, to be fair I never advocated putting all files in one directory, I > advocated placing packages files in logical locations and used apache > as an example of a location which made sense, and that RH moved to > locations which didn't make sense or, confused long-time admins of > apache. I do, however, don't think it's necessarilly a bad idea to > keep a package like apache under a hierarchy like /usr/apache. > (at the very least, get rid of /home/apache, which is my biggest > gripe :)
I thought /home/httpd was bizarre as well. The good news is, as of I think Red Hat 7.0, they did change it to /var/www. I still don't like /var/www, but it does make more sense than /home/httpd (especially in automounted /home situations -- ICK). I usually change my document root to /data or some other such location that is a separate partition or disk. Red Hat's file layout is starting to make more sense for each release. They even moved the samba configs from /etc to /etc/samba. > > It typically makes PATH variables a mess. I'm sure I could think of other > > annoyances about that approach, but I'm pleased that the FHS exists, now, > > and I'm glad to see Red Hat (others?) start to move in that direction. > > Well, in general, /usr/local/[s]bin is almost always in the PATH > variable, and if not, it's one more addition, so I don't really see > that as a problem. True, but I was referring more to the packages that like to put everything including user invoked binaries in a subdirectory, meaning that it must be added to the path. What does make sense, however, is when there are a large number of binaries/scripts that could pontentially conflict with other more common commands, they can be put into a subdirectory and invoked by a wrapper placed in /usr/[s]bin. FreeS/WAN does this with the ipsec command placed in /usr/sbin and all of the subcommands in /usr/lib/ipsec invoked with 'ipsec <subcommand>'. (Well, they actually default to /usr/local/sbin and /usr/local/lib, but I just patch the make file as part of my rpm spec.) > > My basic view is that each package should fit well into the structure of > >the operating system. I'ld rather see config files in /etc/<tool>, transient > >data in /var/<whatever>, read-only stuff in /usr, etc. (that's et cetera, > >not /etc :-)). > > I have no argument with that, just so well as it's logical. For > example, /home/apache, to me, isn't all that logical. I'd rather see > this stuff in /var/apache or /var/www like Debian has it. To me that > makes sense. As mentioned above, RH did at least fix that. > > A package manager such as rpm makes it easy to find stuff. > > I half jokingly say that one of the first things I aim to do to any > >production system that I am given responsibility to maintain is > >'rm -rf /usr/local'. I consider /usr/local for testing, getting something > >up and running quickly, just to try something out, for temporary use only. > > That's actually not a bad idea. (of course, it's completely contrary > to the way I've done things in the past, but I like it :) > > >I put everything I possibly can into an rpm package. To be fair, I've spent > >at least the last four years digging into the depths of rpm and know it > >well enough to do that. > > This here is the problem, though. Now you need to know about a whole > bunch of package managers if you're in charge of a heterogeneous > environment; rpm, dpkg, pkgadd, whatever HP and Compaq use, etc.) Agreed. I was working on a project a while ago to take source rpms and poop out pkgadd packages. I had gotten pretty far, but I only have a dinky little Sparc5 with Solaris 7, so development was kind of slow. Really, I was just writting a bash script which was glue between rpm and epm (http://www.easysw.com). I'ld use rpm to build a binary rpm and then run my bash script to create the epm config file and directory structure and then invoke epm. I worked pretty well, but there were still a number of kinks to work out. > Sure, you could compile rpm for each of them and use rpm for stuff > you add and the native one for base OS stuff, but if you're going to > go that far, why not just put everything into /usr/local from source > and be done with it. > > Though, in the end, the only thing that really matters is that > you should be consistent in whatever you do. Which is why I was working on the project above. Someday, I'll have the motivation to revive it. > > Hell, I even refuse to use a kernel unless I can put it into an rpm format. > >But again, to be fair, I've spent quite a bit of time learning how to > >unravel kernel*.src.rpm files, modify them, and build them with my own > >changes even while I sleep (or in lieu of sleep). > > That's a little extreme for me. especially since I use Debian :) > But seriously, why go through all that effort for the kernel? > (unless you're just trying to be consistent :) Just trying to stay consistent. Makes upgrades more straightforward. Though, admittedly, I have rarely trusted operating system upgrades on ANY OS. I almost always do clean installs and migrate my changes/configs. > > Sorry for the rant. I'm just a bit grumpy because of problems I found with > >evolution 1.0 last night. I'm opened to being convince of the error of my > >ways, but it'll take something I haven't heard before. > > What! Bugs in a 1.0 version of code meant to mimick OutLook? I'm > shocked! ;) :-) Turns out that evolution won't work for users in LDAP and no local /etc/passwd entry. It might work for NIS users -- I didn't try it. The cause is that wombat segfaults while doing the uid lookup. A few minutes ago I found that running nscd is reasonable workaround. Before that, I had to add a local username entry in /etc/passwd, which, to me, is an *un*acceptable workaround. > > Seeya, > Paul > ---- > > God Bless America! > > ...we don't need to be perfect to be the best around, > and we never stop trying to be better. > Tom Clancy, The Bear and The Dragon > > > -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
