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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef6f2d0.5020...@msgid.tls.msk.ru