In <Pine.LNX.4.21.0007280808460.73-100000@rc.priv.hereintown.net> Chris Meadors (clubneon@hereintown.net) wrote:
> On Thu, 27 Jul 2000, Thomas Molina wrote:
>> No I'm not kidding. Based on some comments by Linus earlier, he is
>> advocating putting the kernel source tree out of the way of glibc and
>> other "standard" development tools. /usr/local seems a better fit to me
>> than /lib/modules. According to FHS /lib is for essential shared
>> libraries and kernel modules. It also says one of the uses of
>> /usr/local is for local source code. It's also one of the few places
>> which shouldn't get clobbered in a system software upgrade.
> FHS also says that a distro should ship with nothing in the /usr/local
> tree.
And I find it ridiculous. Yes, for FILES I agree - it's place to install
local files for system. But for directory stubs... Where the hell I must
put local perl packages ? I prefer /usr/local/lib/perl for architecture
specific-ones and /usr/local/share/perl . And I (as dstribuion creator)
even can configure perl to use this directories. But I CAN NOT (according
to FHS) create this directories. Gosh. So now I need to GUEES where I can
put my extension files in /usr/local (or just put system specific files for
perl, tcl, guile and so on in some other place in system - but where ?).
Looks like FHS was created without such packages in mind (even if they are
numerous - emacs, perl, tcl, python, guile, etc: all this packages can be
configured to use OS-specific files and system-specific files just like
C compiler, but FHS supports such thing only for C compiler). Still it's
not kernel problem.
> But the FHS also says you can't have things like /usr/apache. But I find
> that most useful, as deleting one directory removes all traces of the
> program.
Your packager should handle this. If it's not part of OS then it should be
installed in /opt - this part of FHS looks Ok.
> Large packages that would normally end up all over the place can
> be contained (like X, which FHS does allow to have its own place under
> /usr).
IMO the only reson to keep X in there is to make linux more like other unixes.
>> It was an opinion; I'm expressing my 'druthers, if you will. I know
>> others don't agree. I see where it looks as if Linus is leaning towards
>> /lib/modules anyway, so I'll adapt. Or I'll be contrary and make
>> appropriate local changes in the source code. As long as Linus keeps it
>> as a self-contained entity it won't matter anyway.
> /lib/modules seems good enough. But as somone else said, it might make
> more sence to be /lib/kernel. The one problem I see with this, is I
> usually have a small(ish) root partition. On any installation I've done
> /lib has never had its own partition.
It's usually not even possible: you need glibc for /sbin/init. It's why there
are exist /bin,/lib,/sbin and /usr/bin,/usr/lib,/usr/sbin : files in
/bin,/lib,/sbin are needed to support mounting of other parts of system so
you can not put then on separate partition.
> And on most, the root partition hasn't been big enough to hold an unpacked
> kernel tree.
Yeah, kernel source is usually bigger then contents of /bin,/lib,/sbin
(and /etc) combined.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:27 EST