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 [cjwat...@debian.org]