On Sat, 5 Jan 2019 17:23:11 +0100 Mattia Rizzolo <mat...@debian.org> wrote: > Control: reopen -1 > > On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote: > > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki <kurt@kwk.systems> wrote: > > > I was just about to open a bug on this same issue. It's actually present > > > in both libmed11 and libmedc11. Instead of Conflicts, they both need > > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar > > > > In this special case, you probably need to add > > Breaks+Replaces: libmed1v5 (>= 4) > > respectively > > Breaks+Replaces: libmedc1v5 (>= 4) > > since the versions before 4 should not have any file conflicts. > > Actually, I think Breaks+Replaces is wrong here. > > Breaks+Replaces allow for silent replacing of the old package, but here > you need to forcefully remove it, which is what you'd use Conflicts for. > As a data point, that what we usually use when renaming packages during > ABI breaks like what has been done for #916881.
I agree that Conflicts suits better regarding the need to forcibly remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1). > Incidentally, I think that would also cover the just openend #918372, > as with a Conflicts the libgmsh3 package from testing woudln't be > installable, so it would force an upgrade to the version in unstable, > making the test pass. Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 from the broken med-fichier 4.0.0+repack-1 are still present into unstable. Is there a way to have them removed? Thanks, _g.
signature.asc
Description: OpenPGP digital signature