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
