[PKG-OpenRC-Debian] Bug#829488: IRC log discussing the issue

[Thomas Goirand]

We just had a discussion about this bug in the #debian-systemd channel,
and I think it may be helpful. Here's the IRC log:

<zigo> mbiebl_: The bug I was reffering to you during Debconf was: #829488
[zwiebelbot] Debian#829488: dist-upgrading while switching from openrc
to file-rc is broken - https://bugs.debian.org/829488
<zigo> It's not clear to me that it's caused by openrc.
<zigo> I'm not even sure it should be assigned to openrc either.
<zigo> IMO, it's just a big mess ... :P
<zigo> Maybe you know better?
<ansgar> zigo: I think there was some talk about upgrade problems with
file-rc on #-devel yesterday.
<zigo> Cheers, looking.
quit (Quit: Ex-Chat)
<ah> zigo: in jessie, systemd-sysv tries to ensure correct combination
of packages by depending on sysv-rc ... unfortunately openrc provides
sysv-rc, so satisfies that. Which means you can start out with a messy
situation which only goes downhill from there when also throwing file-rc
into the mix.
<ah> zigo: worse is that you can then apparently trick apt into
uninstalling all providers of update-rc.d at the same time because it'll
later on install file-rc, but during that time-window also get apt to
configure random other packages.
<zigo> ah: Wouldn't a Depends: init-system-helpers (>= 1.37~) in openrc
solve the issue?
<ah> no, it's already essential so you shouldn't depend on it.
<zigo> ah: So, if I get this well, update-rc.d moved from sysv-rc to
init-system-helpers, right?
<ah> zigo: the entire problem is highly theoretical, since noone in
their sane minds would install this combination of packages and do this
"dist-upgrade while switching to file-rc".... but in theory it's a
policy violation still.
<ah> zigo: it's a bit more complicated, but basically.
<fsateler> ah: the problem seems to be that apt decided to switch
<fsateler> not the user
<fsateler> openrc installed in jessie, add stretch, dist-upgrad => apt
attempts to switch to file-rc
<ah> zigo: openrc conflicted, replaced and provided sysv-rc because it
would provide its own version of update-rc.d and invoke-rc.d ..... which
was some kind of homebrew scheme instead of using diverts invented by
sysvinit maintainers.
<ah> zigo: openrc support was in stretch merged into the same *-rc.d
already providing sysv,systemd and upstart support... now living in
init-system-helpers.
<zigo> ah: Yeah, I remember why we did that, we needed to add some
features to it.
<ah> zigo: file-rc was "temporarily" fixed to just divert the
init-system-helpers *-rc.d files for now.
<zigo> Oh...
<ah> zigo: so basically init-system-helpers is the one true location for
the *-rc.d utils in stretch, but in jessie it was a mess.
<zigo> ah: So, the fix is probably to get file-rc to use
init-system-helpers then?
<ah> zigo: I see two "fixes" (which is just a way to avoid the
combinations in the testcase), either openrc gets a stable upload that
drops the Provides: sysv-rc
<ah> zigo: or we get file-rc removed from the archive.
<fsateler> also, it would be great for openrc users for a dist-upgrade
to not switch their init system
<zigo> ah: The stable upload is a no-go, that breaks our promise to our
users that you can upgrade from any jessie version to any stretch version.
<ansgar> zigo: That is not promised.
<fsateler> zigo: that is not a promise we make to our users AFAIC
<zigo> Really?
<zigo> So, before upgrade from oldstable to stable, one is supposed to
dist-upgrade?
<zigo> This is the first time I read something like this.
<ah> upgrade should be ok, no need for dist-upgrade.
<zigo> And if that was the rule, I think it should be changed.
<fsateler> zigo:
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-preparations
<fsateler> see point 4.2
<zigo> Anyway, the dist-upgrade switching from openrc to file-rc
definitively needs to be fixed.
<ah> zigo: I acknowledge that stable update of openrc is not perfect,
but I also think working around this issue in all (thousands?) of
packages calling update-rc.d in their maintainer scripts isn't a better
idea.
<zigo> ah: We have about 1500 packages with startup scripts indeed! :)
<zigo> 1200 last time I checked (this was about 2 years ago, so 1500
should be about right)
<zigo> I also wonder if we could completely get rid of sysv-rc in the
favor of openrc.
<zigo> Nobody is maintaining sysv-rc these days: Roger Leight was the
last active "upstream", doing it only for Debian.
<ah> zigo: maybe if you find some apt expert they can tell you exactly
why apt thinks it's ok to uninstall all providers of *-rc.d at the same
time while there are still packages installed that depends on them....
and what you can do to avoid that.
<ah> zigo: pere says he's retired but he's actively providing feedback
for sysvinit.
<zigo> Feedback != maintenance (or patches).
<ah> zigo: getting rid of sysvinit probably something you should discuss
mostly with non-linux porters though.
<zigo> I unfortunately was added to the list of maintainers of
sysv-init: I get loads of very weird bug reports.
<fsateler> so, in jessie, openrc does not conflict with systemd-sysv
<ah> if they want to switch to openrc, then noone will stop them I guess.
<zigo> And I see no bug being closed ... :/
<fsateler> but in stretch they do
<fsateler> so apt decided to upgrade systemd-sysv, and kick openrc out
in the process
<zigo> ah: sysv-rc != sysv-init.
<zigo> ah: openrc needs sysv-init.
<zigo> It only reimplements sysv-rc.
<mbiebl_> zigo: see my bug I filed earlier
<ah> zigo: I personally don't see much point in touching anything
sysv-related more than needed at this point.
<mbiebl_> I think if openrc get's a dep on sysvinit-core
<mbiebl_> this whole situation can be avoided
<zigo> Ah, really?
<zigo> Interesting...
<fsateler> mbiebl_: did you see my above comment?
<mbiebl_> yeah, because you wouldn't have the systemd-sysv + openrc
combination to begin with
<fsateler> openrc does not conflict with openrc in jessie
<fsateler> so that needs fixing in jessie
<mbiebl_> correct
<mbiebl_> that would need a stable upload
<fsateler> oh ok. I thought you meant fixing in unstable was enough
<mbiebl_> dropping the Conflicts: openrc in systemd-sysv will also help
<ah> removing the Provides: sysv-rc or adding Depends: sysvinit-core (in
stable) should basically give same effect.
<mbiebl_> as it will avoid the forceful switch to file-rc
<mbiebl_> well, turning it into a versioned Conflicts
<mbiebl_> ah: yeah
<mbiebl_> both changes seem correct to me
<zigo> mbiebl_: Would you be kind enough to explain this in #829488 ?
<ah> both of them should probably happen for correctness even if only
one is needed.
<mbiebl_> ah: nod
<mbiebl_> ah: all three of them, actually, dropping the provides:
sysv-rc, adding the depends: sysvinit-core in openrc
<mbiebl_> and turning the Conflicts: openrc into a Conflicts: openrc (<<
fixed_version)
<zigo> It's going to be *very* hard to explain to the release team. :/
<ah> mbiebl_: yep
<mbiebl_> fixed_version being the one which switched to using the i-s-h
provided update-rc.d/invoke-rc.d
-*- ah starts wondering if anbe tests stable->stable updates and would
"spot the bug" again if this gets fixed in a stable updated.
<mbiebl_> << 0.20.4-2 if i'm reading the changelog correctly
<mbiebl_> zigo: feel free to copy this IRC conversation into the bug
report :-)
<mbiebl_> if fsateler and ah are fine as well
<ah> no problem
<fsateler> no problem either
<ah> I wonder what effect only versioning the openrc conflict in
systemd-sysv would have... could fix this without the need for a stable
update.
<ah> maybe apt would decide to update openrc first then.
<mbiebl_> ah: most likely, yes
<ah> zigo: btw, looks weird that openrc only Recommends
init-system-helpers... I bet a Pre-Depends like sysv-rc would be a
better idea.
<mbiebl_> I still think fixing the other two issues are worth it
<ah> zigo: because if you get apt to upgrade openrc first, then you'll
likely also be missing *-rc.d for a while.
<mbiebl_> ah: I guess you could still cause that situation manually if
you do dist-upgrade plus the file-rc switch
<mbiebl_> but, oh well
<mbiebl_> the problem here really is, that we allowed such a weird
combination in stable
<ah> given file-rc has no real future anyway, I hope to see it gone
before stretch release....not after.
<mbiebl_> and the switch is done automatically by apt
<mbiebl_> ah: yeah, if mikap really intends to keep it
<mbiebl_> it should at least stop doing the diverting stuff
<mbiebl_> but I'm not to thrilled merging that into i-s-h
<mbiebl_> so +1 for dropping it for stretch