Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Guillem Jover]

Hi!

On Fri, 2017-06-23 at 12:22:34 +0100, Colin Watson wrote:
> The basic problem in init-select is of course the good old favourite of
> a conffile not behaving correctly when the package has been removed but
> not purged.  This is probably worth fixing in unstable as follows, since
> init-select is still there:
> 
> --- a/init-select.cfg
> +++ b/init-select.cfg
> @@ -1,1 +1,1 @@
> -GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $(/usr/lib/init-select/get-init)"
> +GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x /usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"

> However, I take Andreas's point that we need to work around this
> somehow, probably in a stretch point release now, and that's where I
> need feedback.  One possible approach would be to change grub-mkconfig
> to do something like this:

> I fully appreciate that this is skating along the edge of policy's
> requirements regarding conffiles, and arguably violates at least 10.7.4
> "The maintainer scripts must not alter a conffile of any package,
> including the one the scripts belong to".  However, I think that this is
> a reasonable case of self-defence, and could be tolerable with
> sufficient commentary and care.  I doubt I would be contemplating it if
> init-select hadn't been removed from stretch.

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?

Thanks,
Guillem