Re: DEP 17: Improve support for directory aliasing in dpkg

[Helmut Grohne <helmut@subdivi.de>]

Hi Simon,

On Fri, Apr 21, 2023 at 06:05:27PM +0200, Simon Richter wrote:
> The first thing we need consensus on, IMO, is the definition of "complete".

I honestly had hoped that we did have consensus on this point.

> The maintainers of the usrmerge package consider the status quo an
> acceptable technical solution, so their definition of "complete" is to roll
> out the change to the remaining users.

I find this description inaccurate. As is evident from this very thread,
Luca Boccassi considers that there is more work to do and intends to do
some of it.

For clarity let me propose the following requirements for the definition
of done:
 * All files shipped in Debian packages are shipped in their canonical
   location rather than an aliased path.
 * The symbolic links are part of some essential package.
 * Therefore no special handling code is needed in bootstrapping tools
   for future releases.

Would anyone disagree with this?

> The alternative would be a consensus that dpkg is simply not expected to
> always leave the system in a useful state if it encounters certain invalid
> situations, and hoping that we will also be able to point to a few million
> installations where that has not exploded and call it a success, but that
> would need to be communicated.

This is a view that I had initially ruled out as absurd, but I see how
it has some appeal. In essence, our strategy would be based on extensive
testing (and occasionally getting it wrong). It would also be based on
considering the undefined behaviour area of dpkg and integral part of
our solution, which would make modifying dpkg very difficult (as any
innocuous change to dpkg might break things). However, if we can get
past that period, we'd be able to leave the transition behind without
turning dpkg into a Jenga tower (as Guillem put it). I am still not
convinced of this option. My main reason for disliking it is that it
shifts the effort from the proponents to everyone else. The aliasing
effects consume so much mental capacity of regular package maintainers
that I find it difficult to justify enduring that any longer and the
approach essentially encodes this as the way forward.

> Testing alone will be an absolute nightmare because we can enter invalid
> states through multiple avenues, for example, if I have a conflict
> 
>     a.deb: /bin/test
>     b.deb: /usr/bin/test
>     c.deb: /bin -> /usr/bin

Arguably, we can rule out a lot of test cases by policy. We already have
policy that forbids the combination of a.deb and b.deb in Debian. This
property can relatively simply be checked on a distribution level and
therefore I think we can entirely skip this case. So while I agree that
testing will be a difficult part of it, I also think that reducing the
test matrix to what we really need is key to keeping it manageable.

> The latter case is also what should happen if b declares "Replaces: a".
> 
>     # move file to /usr, install symlink, then remove symlink, move back
>     dpkg -i a.deb c.deb
>     dpkg --remove c.deb

Again, I think c.deb would likely be essential and since removal of
essential packages is undefined, we can remove such cases from our test
matrix.

Helmut