:: Re: [DNG] support for merged /usr i…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Simon Hobson
日付:  
To: dng
題目: Re: [DNG] support for merged /usr in Debian
Steve Litt <slitt@???> wrote:

>>     Therefore, if you want to mount a disk partition, you either
>> need the necessary drivers and filesystem built-in the kernel or have
>> them in the initrd/initramfs (under /lib/modules). Having the module
>> on the disk won't help -- egg and chicken.

>>
>>     Didier

>
> If you didn't merge /lib and /usr/lib, you could load them from /lib
> once the root partition was mounted. This was my entire point.


But if the root fs is on a disk attached to a controller that needs a kernel module to use ? Before you can mount / and get access to /lib, you need to load the kernel module that's in /lib - chicken and egg. I have some systems where that applies - eg an HP raid controller needing (IIRC) cciss driver module.

An ability to "link" modules into an already compiled kernel (which is how SCO did it) would make a sensible alternative for probably the majority of users - giving the kernel the ability to mount / and from then on gain access to all the other tools needed to mount anything else.




chaosesqueteam@??? wrote:

> Please keep to the traditional Linux way and keep /usr/ etc as is.
> This shouldn't even be a debate.


There is always room for debate - argument and dictatorship, no; debate, yes. It may be that for the vast majority of users, there is no longer any rational reason to keep /usr - it is a debate well worth having.

> Fork everything if need be, piece by piece (copy on write). I said you'd
> have to do it anyway. The progressives will to infect every piece of userland
> (and maybe the kernel too) they can, so as pieces fall to them it must be forked.


I get the impression that dev resources in this project are "somewhat limited". Yes, in a ideal world the entire Debian toolchain and supporting infrastructure would have been cloned, with every infected item carefully fixed and migrated. Given the lack of resources, it's more important to determine priorities and fix what there is resources to fix.

Trying to do everything when there isn't the resourcing to back it is a a recipe for failure.
So I would suggest it's important to keep focussed on the primary goal and get that accomplished (stable release) so there's something to show as a "success". Then build from there.