On Wed, 2013-12-18 at 16:27 +0100, Josselin Mouette wrote: > Such stances are untenable whenever the kernel is concerned. We need to > be able to use a kernel from the previous stable distribution, or from > the next one, to support proper chroots. This part of the support for > upgrades is needed for our own infrastructure as well as for many of our > users. > > It is possible to handle the situation with udev or with systemd, > because they do not make sense in a chroot environment, but they are the > exception, not the rule. And unless things go hectic, we *will* be able > to treat them normally and provide an upgrade path that doesn’t force > users to do locked upgrades. > > All of this looks very far away from the init system discussion, > though.
I agree this is moving away from init discussion, but I want to address the part about "locked upgrades". Just depending on new kernel features is not the same as "lockstep" as in needing to upgrade everything together (like the case where old udev didn't work with new kernel _and_ new kernel didn't work with old udev). If you upgrade to a kernel with backported features, that obviously should not cause any special issues. And the kernel typically tries fairly hard to keep old userspace working, so even upgrading to a completely new kernel version doesn't mean you have to upgrade the whole userspace. If running the next release in a chroot on your stable machine requires an upgraded kernel package with backported features, or even a completely new kernel version, that's much less of a problem than needing to upgrade the whole OS. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
