Re: from / to /usr/: a summary
On 25.12.2011 12:12, Thomas Goirand wrote:
> On 12/22/2011 07:07 PM, Russell Coker wrote:
>> It seems to me that wanting to have / outside LVM but /usr inside LVM is a
>> fairly obscure corner case.
> I have about 100 servers setup this way, and my laptops as well. I really
> don't see why this would be a corner case. Please understand that many
> different people have many different configuration, and that in today's
> Debian, *absolutely everything is allowed*, and never, ever, Debian said
> that one type of setup would one day be forbidden.
So if a core package which debian relies on will change in a way which
does not support your configuration, should debian stop switching to
a new version of that package? Or should debian fork that package and
maintain it locally forever? Will you do it?
> Taking decisions that some setup are "not supported" would be a bad move
> whatever the partitioning we are talking about. Please don't do that,
> there's no reason why Debian would take such move.
There's a very good reason to have and use current software, as opposed
to a 10 years old one. There's a very good reason to change software.
It is a moot point you're giving - if you want your current - somehow
weird/non-standard/unusual/etc setup to work, just stick with the
software you already using, don't upgrade anything.
For example, in context of this discussion, if the decision will be
made to have /usr available when switching to real root, it will require
either having /usr and / on the same filesystem OR working initramfs
which mounts BOTH / and /usr. If you use a setup now without initramfs
and with / and /usr on separate partitions, there's no way you can
continue to do that with new udev, this is unsupported by upstream.
The postinst script will - most likely - do its best to ensure that
it installs missing parts and creates initramfs for you so your system
will still be bootable, but that's the max it can do, you may need to
sort things after that manually (like updating bootloader configuration
to include initramfs etc). If, at the same time, you're using a custom
kernel which does not support initramfs, there's nothing that can be
done automaticlly, short of installing standard debian kernel.
Again, if the decision will be made. The alternative will be to
a) stick with current udev (which will become incompatible with future
kernels), b) fork udev to patch the missing bits back, c) grow debian-
specific udev. Neither of which is realistic, imho.
> Thomas
/mjt
Reply to: