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 :)
> 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.
> 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.
> 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.)
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.
> 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 :)
> 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! ;)
--
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
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
