Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
> On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> > I'm confused, when I hear you say that this risk is unique to the
> > systemd option and not shared by other options. I would understand that
> > statement if we thought we could avoid systemd entirely. It sounds like
> > we may be able to avoid systemd as pid 1 but systemd is very likely to
> > play an important role in the Debian desktop storpy even if we adopt
> > another pid 1.
> Thanks for the explanation, and apologies to Josselin and Russ that
> I completely misread their point regarding udev:
>
> I was misreading that as referring to the headaches udev had caused in
> the past for Debian upgrades, not that the systemd udev might be the
> cause of future upgrade headaches.
>
> But I do not buy this "We already switched to systemd as upstream of
> udev, so we also have swallow the rest of it":
>
> When not using systemd as pid 1, that risk would be confined to the
> parts of systemd Debian would be using (currently only udev).
I think you still misread the argument: IMO it's clear that it
considered more than udev as likely to be required, even if udev is the
only one in current Debian. So if you disagree, you should at least
address the question of why you believe udev will stay the only one.
> > At some level, we also need to be community players. Since upgrade
> > stability is important to us, we should advocate for it in open-source
> > projects that we depend on. On the flip side, if enough of the rest of
> > the community after having carefully considered our arguments decides
> > that our desire for stability is too expensive, perhaps we need to
> > reconsider our position. I hope we don't need to do that, but sometimes
> > when enough of the rest of the world disagrees with you, you need to
> > move on.
> systemd upstream only reluctantly supports the option to have a separate
> /usr (as currently mandated by Debian policy), and I would not be
> surprised if that gets dropped any time if it becomes an obstacle
> for development of any part of systemd.
You're mixing two separate issues (or at least not clearly indicating
which one you're talking about). Systemd fully supports having a
separate /usr partition, and that is in no way deprecated AFAIK. What
has changed compared to "old practice" is that /usr needs to be mounted
together with root (requiring initramfs if you have a separate /usr;
where you had "mount /" before you now have "mount / and /usr"). Whether
the old way of later /usr mounting could keep working with any other
init either is questionable.
Then there is the move of binaries from /bin to /usr/bin, which does
have some backwards compatibility logic for different paths in systemd.
This is not directly connected to /usr being a separate partition or not
(but having everything in /usr/bin obviously requires /usr mounted
early). Does someone in Debian seriously oppose this move as a long term
goal?
> And now you bring up the point that Debian should reconsider the
> lenght of it's release cycles if systemd upstream decides to not
> support upgrades between distribution releases as far apart as Debian's. [3]
I don't think anyone said that. Nobody talked about long release cycles
not being supported, and nobody said that upgrades would not be
supported either. However, "supporting upgrade from the old release"
does not equal things like being able to run the new userland on the 3+
year old kernel from the previous release.
A development model where you have to wait 3+ years before you can have
hard dependencies on the new features you write now is obviously very
problematic. IMO such restraints should never be taken for granted;
upgrade schemes should always be planned to at least make it possible to
have newer dependencies without too much trouble.
In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts from under a fully live system. This does still
count as fully supporting upgrades.
Reply to: