Hi, On 8/20/21 3:56 PM, Sam Hartman wrote:
Simon's position seemed to be that we need a dpkg update in order to move forward and that we cannot depend on that mid-release.
Yes, except if we give up "apt dist-upgrade" as the interface for the upgrade to the next stable release.
I can see two arguments why we might need a dpkg update: 1) To fix bugs related to directory aliasing. I don't think that there is a consensus those bugs need to be fixed to move forward. (Put another way it's not clear the community agrees they are RC).
dpkg as it is now will detect only the case when a file is moved to the usrmerge path inside a package, or when a file is moved from one package to another (with Replaces), but not both at the same time.
So when I build a test package Package: test1 Version: 1 Architecture: all Maintainer: foo Description: foo containing ./lib ./lib/test and a second package Package: test2 Version: 1 Architecture: all Replaces: test1 (= 1) Maintainer: foo Description: foo containing ./usr ./usr/lib ./usr/lib/testand I install both, then dpkg will have test1 registered as the owner of /lib/test and test2 as the owner of /usr/lib/test. Uninstalling test1 then deletes /lib/test, so /usr/lib/test is also gone.
We can work around that by introducing a policy that no files that are currently registered as living outside /usr may be moved between packages, but... just no.
Good thing /usr/bin/which doesn't need to be moved from /bin, or we'd have our first counterexample already. :/
The current dpkg is also unusable for symlink farming, so I will have to retract my earlier statement about that being a viable transition method: it is not.
Package: test Version: 1 Architecture: all Maintainer: foo Description: foo containing ./lib ./usr ./usr/lib ./usr/lib/test ./lib/test -> ../usr/lib/test fails to unpack on usrmerged systems with unable to open '/usr/lib/test.dpkg-new': No such file or directoryThis is the version of dpkg that will handle the beginning of the "apt dist-upgrade" process for bullseye->bookworm updates, and the point at which dpkg itself will be upgraded is determined by the current version of apt, so our hands are kind of tied here.
IN particular, most systems are usrmerged today, and while these bugs are annoying, many people get along just fine.
Yes, and on all of these systems, dpkg does not have an accurate view of what is installed, so an upgrade to bookworm that moves files between packages is likely to have files vanish, depending on the order in which packages are installed.
Yes, there are bugs. Yes, it would be good to get them fixed in the bookworm cycle. But despite the issue being brought up, there is not strong support for the idea that we must block on a solution to the dpkg directory aliasing bugs.
I think that one of the release goals should be that any freshly installed or upgraded system should have a dpkg database that is consistent with reality, and I'd prioritize that higher than actually finishing the transition, because as long as we can have files vanish from under us, we can't expect that the transition will be reliable for bullseye->bookworm updates.
Basically, we've been lucky so far.
2) We might need a dpkg update to actually do the transition.
Yes, that was my symlink farmer idea, but that doesn't work: special-case replacing a directory that only contains symlinks with a symlink, the same way GNU Stow tries to create its symlinks on the highest possible level, but since dpkg refuses to even unpack a package that contains a compatibility symlink and the file itself on an usrmerged system, this won't work.
Since we need a mechanism to clean up the mess the usrmerge package left us with, adding this mechanism to dpkg itself might still be a good idea -- while that isn't the first package to be upgraded, it is among the first, so we can create a safe environment for later packages and thus minimize the number of packages we have to leave in "reinstreq" state.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature