On Wed, Apr 26, 2023 at 07:11:10AM -0600, Sam Hartman wrote: > >>>>> "Simon" == Simon McVittie <s...@debian.org> writes: > > Simon> You might reasonably say that "the maintainer of bar didn't > Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar - > Simon> and it is! - but judging by the number of "missing > Simon> Breaks/Replaces" bug reports that have to be opened by > Simon> unstable users (sometimes me), it's a very easy mistake to > Simon> make.
Indeed, I was thinking that we correctly to Breaks and Replaces. I now know better and files an initial batch of four rc bugs for missing cases. So yeah, quite clearly we need to fix this more systematically, but I think that's technically possible: 1. Download all Contents and Packages files for stable and testing. 2. Generate candidates for file conflicts from the Contents. 3. Skip cases covered by Breaks+Replaces or Conflicts. 3b. Optionally also parse binarycontrol.d.n data to be able to skip known diversions. 4. Create a fresh stable chroot and install the "old" package. 5. Update sources.list to testing and download the "new" package. 6. dpkg --auto-configure --unpack new.pkg. 7. Check output for "trying to overwrite". > Is adding the correct breaks/replaces enough to solve things? > I could believe adding a versioned conflicts would be sufficient, but it > is not obvious to me that breaks/replaces is enough given that dpkg > doesn't understand aliasing. It is not. > My intuition (and I have not worked through this as much as you) is that > any time you can have files moving where both packages are unpacked can > create problems. This is exactly the situation that caused the moratorium. > I think that can happen with breaks/replaces but not without a conflicts > (without replaces?) Yes, Conflicts can in situations where Breaks+Replaces would fail due to the aliasing issue. My mail from yesterday goes into more detail and also explains when you cannot use Conflicts. Helmut