Control: severity -1 serious Hi,
On Tue, May 23, 2017 at 09:27:14PM +0200, John Paul Adrian Glaubitz wrote: > > I can reproduce this issue in a fresh Debian stretch system if > > required but I was presuming that an upstream bug report was > > appropriate in this case, apologies if I was mistaken. > > Yes, you should definitely always go this route when reporting bugs, at > least when you consider your derivative a distribution on its own. > > However, the fact that this was not reported against vanilla Debian > is not the main reason why I am downgrading this. The main reason is, > as explained before, that Debian officially supports only systemd and > therefore only issues with systemd are considered release critical, > i.e. relevant for the next release. If one of the alternative init > systems don't work as expected, it's a pity but actually not release > critical. If a package leaves the system in a broken state, that is very much release critical. So I'm upgrading the bug to serious. It should probably be 'critical' (breaks the whole system), but as both are RC, that doesn't matter that much. > As the init system is a rather fundamental component of a Linux > distribution, it affects many other packages, directly or indirectly > and it's therefore too much of a burden to provide support for all > init systems available in Debian. Although runit is available in > Debian, it does not mean that it has to be fully supported. If an init system is shipped in a stable release, it has to be supported. Otherwise it should not be in a stable release. > The fact that it is in Debian is merely of the result of Debian's policy to > not limit packages from entering the distribution unless the license or > other serious concerns prevent it. No. If it's broken, it should not be in a stable release. We can still remove this package. > This policy is a result of Debian's decision to adopt systemd as > its default init system [1] as well as the follow up general > resolution [2] where Debian Developers decided that providing > support for alternative init systems was not mandatory. > Furthermore, as also already explained, the problem you have run > into cannot really be trivially solved as the installing runit > does not replace the running instance of systemd with runit so > it is to be expected for commands like 'poweroff' and 'reboot' > to not work until the machine has been rebooted. The fact that problems cannot be trivially solved doesn't mean they are not RC. Also, I don't see how it can be 'expected' that reboot doesn't work until you reboot. How is this supposed to work? Doing a hard reset of the machine? > A possible solution would be to modify the runit postinst scripts > in a way that it does not automatically overwrite the symlinks > for the the above commands until the machine has been rebooted > (e.g. by placing a script which is run only once after the system > has been first rebooted with runit) so that the 'poweroff' and > 'reboot' commands are still sent to systemd. However, the lack of > a reply of the runit maintainer to this particular bug report seems > to indicate that there is currently no interest for such a solution. If the maintainer isn't interested in making sure that this package works as expected, it isn't fit for a stable release... > Thus, in order to prevent this bug report from blocking the release > of Debian Stretch, I have reduced its severity to 'normal'. You > are still welcome to propose a patch to address this issue though, > it's just not relevant for the upcoming Debian release. This is not a good reason to downgrade a bug. Cheers, Ivo
