Bug#727708: systemd jessie -> jessie+1 upgrade problems
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.
Reply to: