Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> >>>>> "Adrian" == Adrian Bunk <bunk@stusta.de> writes:
>
>
> Adrian> Yes, it is speculation that other new features (or even
> Adrian> bugfixes) might appear in the kernel and might become
> Adrian> mandatory in systemd between jessie and jessie+1.
>
> Adrian> But that is a risk, and it is a risk that is unique to the
> Adrian> systemd option since none of the alternatives is
> Adrian> Linux-only. [2]
>
> Adrian> My whole point is not about kdbus specifically (which might
> Adrian> even end up in the jessie kernel), but about that (IMHO
> Adrian> substantial) risk.
>
> 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.
>
> It seems like if systemd starts depending on a new kernel feature then
> it might well need that feature even when not running as pid 1.
>
> So, when evaluating the opportunity costs of this risk in the pid 1
> debate it seems like there are two important mitigating circumstances:
>
> * The extent to which upstream will provide stability, reducing the risk
>
> * The extent to which we cannot avoid the risk even if we choose another
> pid 1, reducing the portion of the cost of this risk properly in-scope
> for this bug.
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).
And since Ubuntu will also be in the "no systemd and supports upgrades
from 2 year old releases" camp, chances are that there would be
solutions available that Debian could use.
As an example, if the systemd udev gets a hard dependency on a too
recent kernel or on systemd internals, there might be a fork of udev
that provides a standalone udev that is suitable for Ubuntu and Debian.
>...
> 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.
That point you bring up is semi-orthogonal to the upgrade decision,
but it also brings up two important points that have to be considered:
1. What is the governance model of the systemd community?
This might be a bit polemic, but I'd fear that your "enough of the rest
of the community after having carefully considered our arguments decides"
might end up being the same as "if Lennart decides it does not match his
vision of how things should work".
This is a real issue since systemd is attempting to absorb a lot of
essential Linux functionality, giving whoever makes the decisions in
systemd a lot of power over policies affecting all distributions
using systemd.
And
2. Does anyone have a complete overview of what Debian policies might
have to be changed now or possibly at some later time as a result
of making systemd pid 1?
systemd does not support non-Linux kernels [1], and realistically using
systemd as pid 1 in jessie will kill all non-Linux ports of Debian. [2]
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.
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]
There are likely more areas where Debian would have to adapt if using
systemd.
The more I think about it, the more I wish the TC would decide:
* jessie will continue to use sysvinit, and the TC will re-evaluate
the situation after the release of jessie
Rationale:
- as time passes, the kernel<->systemd interface will become more
stable [4], reducing potential upgrade problems and
- the full consequences of a switch to systemd on various areas
of Debian will become more clear
cu
Adrian
[1] which is not an unreasonable design decision considering what
systemd aims to do
[2] with 1200 init scripts in Debian, I do not see how it would be
feasible to ensure that several different implementations of each
will be of equal quality in the long run - especially considering
that soon only very few Debian developers would not be using systemd
on their machines
[3] I would definitely appreciate if Debian would have a new release
once or twice a year, but I think that is not a decision that
should possibly be dictated by systemd upstream
[4] new features systemd wants like kdbus will already be in the kernel
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: