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 <ntyni@debian.org> 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
grub-coreboot bug):
> 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 [1]) Bugs: init-select: #858528, jessie-pu: #866643
[1] https://piuparts.debian.org/jessie-rcmd/pass/cqrlog_1.8.2-1.1.log
Andreas
Reply to: