Your message dated Wed, 16 Aug 2017 18:58:32 +0200
with message-id <878tija1qf@whist.hands.com>
and subject line Re: Bug#865929: Advice on dealing with GRUB upgrade failure
caused by init-select
has caused the Debian Bug report #865929,
regarding Advice on dealing with GRUB upgrade failure caused by init-select
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
865929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Preamble
I would like to seek advice from the Technical Committee on the proper
resolution of #863801. This is (for once) not a matter of
irreconcilable disagreement among developers, but one where the only
sensible technical resolutions I can see are in clear conflict with
generally-reasonable requirements in policy.
Constitutional status
-
My belief is that I would ordinarily be responsible for this decision in
my capacity as the main active maintainer of grub2, and that in the
circumstances I could keep the policy violation narrow enough that it's
unlikely that anyone would be particularly inclined to make an issue of
it. However, on advice from debian-devel, I'm seeking advice under
§6.1(3) anyway because of the unusual situation (and so I believe that
the "last resort" injunction in §6.3(6) does not apply).
It may be that the right thing to do involves changing our technical
policy documents, but since I'm not absolutely sure of the correct
approach yet I haven't troubled the policy list with a discussion on
that, so I'm not asking for a decision under §6.1(1); I'm happy to
propose policy changes if the committee believes that to be part of a
proper resolution.
Summary
---
init-select was introduced in January 2014 around the time of the init
system debate, with the intent of providing a straightforward way for a
user to select a non-default init daemon. It provides a debconf
interface to select between sysvinit, systemd, and openrc (and formerly
upstart as well). It operates by setting a variable in
/etc/default/init, and installing a conffile in
/etc/default/grub.d/init-select.cfg which adds an init= parameter to the
default kernel command line set by GRUB.
The grub2 extension facility used by init-select was added by me,
unrelatedly, in January 2013. At present it's maintained as a
Debian-specific patch to source /etc/default/grub.d/*.cfg after
/etc/default/grub, in the spirit of many other such *.d directories in
Debian. Any error in sourcing any of these files will cause
grub-mkconfig to exit non-zero: while this is partly due to the usual
shell "set -e" rules and would be quite difficult to avoid, I also think
it's generally appropriate here.
The conffile installed by init-select has a bug of a kind often found in
conffiles that arrange to execute programs: when init-select has been
removed but not purged, it will fail (exiting non-zero) rather than
realising that it is in a removed-but-not-purged state and silently
doing nothing. This results in various grub2 binary packages failing to
upgrade when init-select is in this state.
init-select was removed from stretch because of #830897: it depends on
sysvinit, which was a transitional package in jessie and was removed
from the archive in stretch. The appropriate fix would have been to
depend on sysvinit-core instead, but the maintainer did not react and no
other developer chose to issue an NMU. As a result, it will typically
be removed as part of upgrades from jessie to stretch, exposing any
users who had previously installed it to #863801.
init-select was removed from unstable in response to #865752, following
a discussion about this general problem on debian-devel.
Considering the upgrade problems that may result from this, I'd like to
find a solution that I can reasonably implement in a point release of
stretch.
Possible grub2 changes
--
These are laid out in more detail in my debian-devel post, linked below.
I considered but rejected the idea of having grub-mkconfig explicitly
ignore errors from /etc/default/grub.d/init-select.cfg, or having it
ignore that file altogether. That option offers no long-term cleanup
path, and so I would have to retain an ugly patch in perpetuity.
I could have NMUed init-select in both unstable and stretch with a
corrected conffile (and probably also with a corrected sysvinit
dependency), and then arranged for the relevant grub2 postinst scripts
to replace /etc/default/grub.d/init-select.cfg with a corrected version
when appropr
