Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
On Sun, Jun 25, 2017 at 11:37:13PM +0100, Colin Watson wrote:
> 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.
I also think this is acceptable.
As init-select is gone from stretch and sid, and particularly given the
other circumstances, I think you should feel free to take over management
of the offending conffile that used your extension facility.
Viewed this way, I'm not sure there's an inherent policy violation here
at all (assuming you only remove the file if it's unmodified etc.)
All you're doing is adopting a configuration file and removing it on
upgrade as obsolete.
Obviously moving configuration files should only be done between
cooperative packages and hostile takeovers are not OK, but that's not
an issue here.
If init-select actually had a future in sid/buster, things would be
a bit messier I think...
As for possible policy changes, this seems such a corner case to me that
they'd be a bit overkill. But I'm certainly not opposing such changes.
--
Niko Tyni ntyni@debian.org
Reply to: