Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
On Mon, Feb 19, 2024 at 09:53:20AM +0000, Matthew Vernon wrote:
> On 12/01/2024 12:31, Helmut Grohne wrote:
>
> > For the gzip case, we have the additional question whether we tolerate
> > the temporary policy violation for the trixie upgrade or halt the
> > /usr-move and retry with a modified dpkg (that could land in trixie, so
> > we could complete in forky).
I note that this question fortunately no longer is relevant. The problem
there was that when zutils is removed as part of the upgrade, there was
no fixed zutils that could help with resolving the situation. Turning
this insight upside down means that gzip's maintainer scripts have to
help here. That's what I ended up proposing in
https://bugs.debian.org/1059534#30 and as likewise for
cryptsetup/cryptsetup-nuke-password and isc-dhcp. While none of these
has reached unstable yet, no problems are known with this approach
beyond being a layer violation: The diverted package now has to support
the diverting package in managing its diversions (until trixie is
released).
> What's the scope of dpkg modification needed here? And is likely the sort of
> thing the dpkg maintainers would accept. Were we not already in a bit of a
> mire here, it's not clear to me that policy is wrong here (and thus that we
> should set it aside).
I discussed a possible temporary feature of dpkg with Guillem. We could
temporarily (trixie+forky) change the semantics of dpkg (and then revert
the change). Whenever dpkg is about to delete a file, it would determine
the realpath of the file to be deleted according to the filesystem. This
is a noticeable slowdown as deletion is a frequent operation in package
upgrades. It would also require reimplementing dpkg-realpath in C (there
is a poc). When the realpath of the file to be deleted differs from the
looked up filename and is found to be owned by a package in the dpkg
database, dpkg would skip the deletion and issue a warning. The warning
would serve as a reminder that this changed behaviour should not be
relied upon for future upgrades. The reason we discarded this option was
timing: Using this approach would have meant that we could only start
moving files after the release of trixie.
Bumping back this transition seems harder and harder now. I think we are
half-way through the conversion (in terms of package count) with a focus
on non-trivial situations. Moving back would cause significant breakage
at this time.
> This continues to make me worry we are not on the path of robust
> engineering. But I appreciate I'm in a very small minority in that regard.
This was known right from the start of DEP17 when Luca Boccassi proposed
"let's just move all the files". We immediately identified that this
path was not robust spelling out a significant fraction of problems
right from the start. I tried to reconcile consensus repeatedly and
there were little objections when I concluded that we'd move forward
with this despite its known fragility.
Helmut
Reply to: