2000-07-28 20:49:26

by sl

[permalink] [raw]
Subject: Re: RLIM_INFINITY inconsistency between archs

In article <[email protected]>,
Chris Meadors <[email protected]> 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.
>
>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. 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).

You can do that in /opt or /usr/local if you like.

>> 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. And on most, the root partition
>hasn't been big enough to hold an unpacked kernel tree.

/lib/modules is probably the easiest place to get some agreement. The
contents of that directory is not specified as of FHS 2.1.

This discussion should probably be done on the FHS list so that the
results can written up in that document. It currently mandates that
(for example) /usr/include/linux points at /usr/src/linux/include/linux.

--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.fireplug.net 604-461-7532


2000-07-28 23:58:12

by clubneon

[permalink] [raw]
Subject: Re: RLIM_INFINITY inconsistency between archs

On 28 Jul 2000, Stuart Lynne wrote:

> In article <[email protected]>,
> Chris Meadors <[email protected]> wrote:
> >
> >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. 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).
>
> You can do that in /opt or /usr/local if you like.

Just because so many (2 or 3) people have mentioned this to me I'll reply
to it shortly.

The problem I have with /opt is I'm not used to it yet. I'd have to put
it on it's own partition just like /usr, /home, and /var. I don't have
any feeling for how big /opt should be and I usually totally just forget
about it.

I'm building a new system now, I'm going to attempt to make use of /opt
for larger, self-contained packages. BUT /opt is going to be a symlink to
/usr/local (take that FHS). At least now I'll get a little more used to
using /opt.

Boy, I can't think of one thing to say that'll make this relevent to the
kernel.

Chris Meadors (at home)