Bug#727708: systemd jessie -> jessie+1 upgrade problems
Hi Adrian,
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.
Systemd’s development is driven by the needs of its users. It has even
incorporated a lot of Debian’s needs, despite our choice so far to delay
its inclusion. It has used some of Debian’s good practices
(e.g. /etc/hostname or /etc/timezone) as a basis for standardization
across other distributions.
> 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.
Things work the other way round. Debian will have more weight in the
future of systemd if we adopt it. It is unreasonable to ask an upstream
project to conform to your policies if you don’t even use it. We need to
play with the community: embrace systemd, and use that weight in the
decisions affecting its future.
Let’s consider the kdbus example in this light. If Debian is a major
systemd player, it is more likely that upstream will support a fallback
to the old dbus-daemon until a kdbus-enabled kernel makes it to a stable
Debian release, or at least makes it easier for us to maintain that
fallback. If Debian does not pick systemd, what is the point for
upstream in making their software more complex for the benefit of
nobody?
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. Leaving
out important features until a hypothetical date, just because we fear
our own skills and ability to provide smooth upgrades, doesn’t sound
like a great plan to me.
> 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.
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.
> 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), but this is irrelevant
to the choice of an init system.
> 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. At least the upstart
proponents have outlined a strategy to keep software depending on
systemd interfaces working in jessie.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: