Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
Control: block 866643 with -1
On Wed, 28 Jun 2017 22:34:41 +0300 Niko Tyni <email@example.com> wrote:
> 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
> 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.
On 2017-07-02 03:15, Guillem Jover wrote to #863801 (the corresponding
> Isn't the obviously correct and policy compliant approach to just
> Conflicts/Replaces (or Breaks/Replaces depending on the force you want
> to apply here) with the init-select package from one of the grub
> packages, and on that grub package ship a stub init-select.cfg with
> just a comment explaining what's going on. And in the next release cycle,
> just make that package remove its (now) own conffile?
(Guillem explained this in a better way than my similar suggestion)
For completeness: init-select needs to be fixed in jessie-pu, since it
will fail to install/remove if mysql-server is installed, but apparmor
is not. (This is unfortunately not flagged as a failure by our regular
piuparts tests ) Bugs: init-select: #858528, jessie-pu: #866643