Bug#919915: grub2-common: fails to upgrade from 'stretch-backports' - trying to overwrite /etc/kernel/postinst.d/zz-update-grub from grub-cloud-amd64 0.0.4~bpo9+1
On Sun, Jan 20, 2019 at 10:08:46PM +0100, Bastian Blank wrote:
> On Sun, Jan 20, 2019 at 05:46:27PM +0000, Colin Watson wrote:
> > It isn't me who needs the policy lecture here - this is grub2-common's
> > configuration file, and the version of grub-cloud-amd64 in
> > stretch-backports seems to have decided that it's OK to overwrite it
> > unilaterally. This is not OK. Bastian, if you need the update-grub
> > snippets to be modified for some reason, then you need to coordinate
> > with us to get the change into grub2-common rather than just shipping
> > your own version.
>
> This is the state pre-#910959, so grub2-common does not yet include the
> file. This means all binary packages that install grub need to ship
> them separately, that's what grub-cloud-amd64 does.
Ah, yes, I'd forgotten about #910959.
Why don't you ship the files under different names, though? There's no
reason they have to be called "zz-update-grub". The worst consequence
of e.g. "zz-update-grub-cloud-amd64" would be possibly running
update-grub more than once during upgrade, which is certainly better
than hijacking another package's conffile. Even that shouldn't happen
much in practice as grub-cloud-amd64/stretch-backports conflicts with
most of the other packages one is likely to install that ship
zz-update-grub, and you could just leave those conflicts in place in
stretch-backports if you were concerned about multiple runs of
update-grub.
A workable approach would be:
* 0.0.4~bpo9+2 in stretch-backports moves the conffile to a
non-colliding name
* 0.0.4.1 (or whatever) in buster removes that non-colliding name on
upgrade
I could probably put together NMU patches for you if you don't have the
time.
> > I'm happy to add Breaks/Replaces, but first the version of
> > grub-cloud-amd64 in stretch-backports needs to be fixed to stop
> > hijacking grub2-common's conffiles. After that has been done, I would
> > be happy to add Breaks/Replaces on grub-cloud-amd64 (<< fixed-version).
>
> There is not way to define Breaks/Replaces relations that only match on
> the package variant in backports.
Why would that be necessary? If you can confirm that >= 0.0.4 isn't
going to have this problem, then Breaks/Replaces grub-cloud-amd64 (<<
0.0.4) in grub2-common would surely be fine; it wouldn't cause a
practical problem if it's slightly overbroad. I'd prefer (<<
0.0.4~bpo9+2) if at all possible though.
(It's not even particularly overbroad anyway, since AFAICS 0.0.3 is the
only version matched by that relation that didn't have this bug, and
that isn't the current version in any suite.)
> Maybe I'll try to add a dependency grub2-common (<= fixed-#910959).
Please don't: that wouldn't help this upgrade problem (as dpkg would be
completely entitled to just deconfigure grub-cloud-amd64 before
unpacking the new grub2-common), and adding non-useful constraints to
the dependency graph only makes upgrades more complicated.
--
Colin Watson [cjwatson@debian.org]
Reply to: