Status of prompting / notification on upgrade for init system switch?

[Martin Pitt]

Hello Russ,

Russ Allbery [2014-10-18 20:59 -0700]:
> When one of you has a chance, could you update this bug with the current
> thinking around how to handle upgrades

I'll leave this to the Debian maintainers, as I'm mostly responsible
for the Ubuntu side, haven't really discussed this with the two
Michaels/Tollef/Marco, and I don't feel qualified to speak for the
Debian systemd team.

My personal opinion: Given how close we are to the release and how
many regression reports we still get, it seems prudent to not change
the currently running init systems for upgrades for Jessie yet, but
only set up systemd for new installs. I know this is not really in the
spirit of the TC decision to make systemd the default init system, but
at this point in time it might be the pragmatic compromise.

The systemd package gets literally swamped with bug reports (of all
kinds of usefulness/quality), and there's simply not enough
maintainers to keep up with the flood. Many of those are indeed not
actual bugs in systemd, but bugs in other packages, local
misconfiguration, or mere misunderstanding, but a fair amount *are*
bugs in our integration (for the release it doesn't matter that much
whether they are in systemd itself or other packages).

The one thing that I'd really like to avoid is interactive prompting.
As much heat as the init system debate produced, from an user's POV
it's pretty much a tempest in a teapot. Quite frankly, as a user
I don't care that much about init systems, I just want my system to
boot and "apt install mysql" to DTRT. Moreso, do we really expect a
user to make this decision on upgrades? Look how hard it was even for
us as DDs or the TC to make an informed decision -- I really don't
want to push this to the user:

 [ ] Install init system A (may degrade some things)
 [ ] Install init system B (may break some things)

IMHO it's a distro's job to make this qualified decision for the user
based on which system he upgrades or installs.

> around the ordering of dependencies in libpam-systemd, and some of
> the other ideas (such as attempting to detect systems with
> /etc/inittab configuration or init scripts that don't follow
> systemd's assumptions) raised in those threads?

I haven't looked at those in detail. It's great to see that people
work on such heuristics for upgrades, but TBH it always takes a while
to stabilize those.

> I would be particularly interested in your take on the analysis that Steve
> Langasek posted to the debian-devel thread on why listing systemd-shim as
> the first alternative dependency for libpam-systemd makes sense and should
> not cause any negative effects for systemd users.

As https://bugs.debian.org/765101 showed, installing systemd-shim has
not always been entirely inert/regression free under systemd as pid 1,
but to be fair this has been the only bug of that kind ever, and
there's a better solution proposed in that bug which will make this
never happen again.

The other direction (running sysvinit or upstart with -shim) has not
been so unproblematic though, as systemd-shim's bug list shows. This
definitively needs some love, but then again we've run this for a fair
while in Ubuntu (even in our 14.04 LTS) without too many problems. So
my feeling is that we can certainly stabilize -shim by the jessie
release. (We need to do that anyway, as we need to support sysvinit
regardless of what we do on upgrades/new installs.)

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20141020/b1a9d609/attachment-0002.sig>