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
