Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
> Hi Adrian,
Hi Josselin,
> Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
> > 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 red herring that has been recurrently agitated, on the basis
> of the PulseAudio experience, but so far it has never proven to have any
> basis in reality. Just because Lennart is a developer in both projects,
> doesn’t mean they have the same governance model.
the *so far* is the worrisome part, considering how much power to
enforce policy whoever controls systemd has.
Switching to systemd also implies to trust that Lennart will do the
right things.
I am not in a position to judge whether or not Lennart should be
trusted, but everyone should be aware that this trust in Lennart
is a requirement for a switch to systemd.
>...
> Maybe it will not work. Maybe the cost for upstream will be too high
> regardless. I might have to remind you that the sarge→etch upgrade had a
> locked-in upgrade of udev and the kernel. The world did not crumble, and
> we didn’t abandon our policies just because we had to make an exception.
> (Actually this upgrade was much smoother than the python shit in
> squeeze→wheezy.) We made it work that time, and if, despite our efforts,
> we have to make another exception, we will make it work again.
We already seem to agree that the statement in the systemd position
statement that "does not have any impact on the ability to upgrade
systems" is not correct.
There might potentially be non-trivial jessie -> jessie+1 upgrade
problems with systemd, and even though such issues will likely be
work-aroundable with an unknown amount of effort, they are something
to take into consideration.
> Leaving out important features until a hypothetical date,
What exactly is the list of features that are lost as of today if Debian
uses in jessie the logind from the systemd 204 package in unstable and
perhaps work Ubuntu has done for a non-systemd system?
This won't solve the issue long-term, but it would give us 2 more years
to observe how the whole init system situation develops.
> > 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.
>
> This is another red herring. The Debian code to support a split /usr by
> mounting it from the initrd is simple, and not likely to be broken by
> any new developments.
Are you saying that Debian will not use the --enable-split-usr configure
option of systemd, and therefore won't have to change policy if it ever
goes away?
> I see much irony in seeing people fear for non-Linux ports, for one of
> which we have maintained easy patches for years allowing for a
> merged /usr, and at the same time argue that maintaining a split /usr
> for Linux will be hard.
See my question above.
On a general note, neither non-Linux kernels nor a split /usr are
something I consider extremely important myself. But these are examples
for policy decisions that might be caused by a switch to 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]
>
> Well, of course we should reconsider the length of our release cycle
> (and make it 3 years like major OS players do),
You miss the critical difference:
Red Hat does not support upgrades between major releases of their
enterprise distribution.
> but this is irrelevant to the choice of an init system.
It is not, when the init system might cause upgrade problems.
> > 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
>
> This option does not look realistic to me.
See my question on that issue above.
> At least the upstart
> proponents have outlined a strategy to keep software depending on
> systemd interfaces working in jessie.
The worst case would be that Debian switches init systems in jessie
(e.g. to upstart) and then again in jessie+1 (e.g. if systemd then
turns out to be the best solution, or if Canonical abandons upstart).
> Cheers,
cu
Adrian
--
"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: