Hello Adam Borowski. This bug report is unfortunately getting offtopic from its original purpose and there's cross-fire with #829488 ... :/
On Thu, Jul 14, 2016 at 03:33:22AM +0200, Adam Borowski wrote: > On Thu, Jul 14, 2016 at 01:15:31AM +0200, Thomas Goirand wrote: > > Continuing our discussions in #debian-systemd, here's what need to happen. > > > > <ah> openrc (stable + sid): add Depends: sysvinit-core, > > That's wrong -- openrc works fine with most if not all modular inits. In So add them all as alternatives! > Debian that's currently only sysvinit-core (maybe also busybox?), but a So there are no alternatives. Depends: sysvinit-core it is. > number of derivatives experiment with or use others, there's no reason to > make their life harder if a better way to represent this relation exists, Derivates could add the alternatives they have... or you could include them in Debian already even if they're not available in Debian. Just dropping the Dependency relationship altogether because multiple theoretical alternatives exists is not policy compliant. As far as I understood zigo you need atleast one of them installed and thus you must ensure that with a Depends. Please note that your luck is about to run out on your missing sysvinit dependencies as their priorities are about to get lowered to optional so won't be installed by default in a regular system anymore. You'll have to explicitly pull in the things you need for openrc to have a chance of working in the future. > ie, Conflicts: with systemd-sysv. Which happens to be already in place. No it's not. $ apt-cache show openrc | grep Confl Conflicts: file-rc, sysv-rc > > It'd also introduce a circular Depends: which is a no-no. There's nothing in the archive which depends on openrc. How could it create a dependency loop? Please inform me about the loop you're seeing. > > > Drop Provides: sysv-rc > > Sounds good, it'd be easier to manage relations with real sysv-rc. > > It's not that trivial a change, though: there's a number of packages whose > relations need to be transitioned. Quite a small number and I doubt you want to touch the src:sysvinit ones. > > bum > lbcd > puppet > rcconf > sysv-rc-conf > initscripts > sysvinit-core > > Some of those may need real sysv-rc rather than openrc, too, which is an > extra reason for such a transition, but we don't know which do. File bugs against those that has wrong dependencies. Playing tricks is not the way to resolve the situation. Likely you'll mostly want to focus on asking puppet to drop their sysv-rc | file-rc dependency and you should mostly be done. This isn't a critical or blocking issue though but can happen over time. > > > <mbiebl_> plus depends on initscripts, to be safe > > Probably, yeah. > > > <ah> openrc (sid/stretch): replace Recommends: init-system-helpers with > > Pre-Depends: init-system-helpers (>= 1.29) and add Depends: initscripts > > M'kay. Please note that this part is critical. Without the pre-depends openrc can get upgraded to a version no longer providing update-rc.d/invoke-rc.d while i-s-h has not yet been installed. > > > <ah> systemd-sysv: Make Conflicts against openrc versioned << y.z. > > Why? I don't think it's a good idea to have two rc systems installed > together, and as you want openrc to Depend: on sysvinit-core, you appear to > want to preserve that Conflicts:. Having both installed isn't a good idea isn't the same thing as what policy says about Conflicts. The packages *can* be installed together and thus should not conflict. The problem in #829488 comes partially from the dist-upgrade + switch to file-rc, which is triggered by openrc + systemd-sysv being ok in Jessie but not in Stretch so apt tries to resolve it and thus file-rc pops into the equation (as noticed by fsateler). The same combination rules need to apply in both Jessie and Stretch to avoid apt switching out your init system. Thus the suggestion to drop the Provides: sysv-rc in stable which would make the stable combination impossible (same as in stretch). Same thing would happen if you instead/also did Depends: sysvinit-core in stable. I'm going abroad tomorrow and will not have much chance to followup but I hope the information we've provided should help you resolve the issues within openrc. FYI Michael Biebl even tested it for you and confirmed the recommendations we provided actually solves the problem in practise. Regards, Andreas Henriksson
