Re: DEP 17: Improve support for directory aliasing in dpkg
On Wed, Apr 26, 2023 at 07:11:10AM -0600, Sam Hartman wrote:
> >>>>> "Simon" == Simon McVittie <smcv@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
Reply to: