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 appropriate conditions apply. This would have violated policy §10.7.3/10.7.4. However, this option is at least in part no longer available since init-select has been removed from unstable (at least not without reintroducing it, which I don't wish to do). I could arrange for the relevant grub2 postinst scripts to remove /etc/default/grub.d/init-select.cfg entirely when appropriate conditions apply. In addition to a self-defence argument, this is further justified by the fact that grub2 now provides a similar facility of its own as of 2.02~beta2-20: if other init daemons are installed, then grub-mkconfig generates additional menu items for them (although there are no arrangements to migrate the default choice from /etc/default/init). This would still violate policy §10.7.3/10.7.4, although it seems to be the favoured option of the debian-devel thread, and it is the least bad option I can see so far. Possible policy changes ----------------------- The primary intent of the sections of policy governing configuration file handling, at least insofar as it's relevant to this issue, is to preserve user configuration and to avoid unnecessary conffile prompts. Packages must remove configuration files on purge, and should remove obsolete configuration files without local changes on upgrade. In the case of a shared configuration file (which is not really the case here, but it's related), policy requires a clear interface between the two packages. Policy does not at present contemplate the situation of an obsolete *package* with configuration files whose presence causes grave-severity problems for another package. Should it do so? We might, for instance, grant a package that is being extended by configuration files from some other package some additional authority to clean up problems caused by that, or perhaps make some general provisions about this quite common kind of configuration file extension interface. Of course we wouldn't want to suggest that packages could play core wars with each other in the archive. References ---------- https://bugs.debian.org/863801 https://lists.debian.org/debian-devel/2017/06/msg00283.html Thanks, -- Colin Watson [cjwat...@debian.org]