On Fri, 2021-08-20 at 23:15 +0200, Simon Richter wrote: > 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. Forgive me, but you have made this statement a few times now, and each time you have been asked for a reference to what usrmerge-specific measures were adopted in Ubuntu's distro updater to justify it, but so far I have not seen any (I might have simply missed it, in which case I apologize in advance). Could you please share such reference(s) so that we can understand what you are referring to? > > 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. Your example is essentially having /bin/foo and /usr/bin/foo at the same time, while not being bit-by-bit identical. I was under the impression that this was already considered RC-buggy and has been for a long while? Am I mistaken and is that not the case? If so, how common is it in the archive, do we have numbers? > > 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. Why has this not happened upgrading from Buster to Bullseye? Or 19.10 to 20.04? Or 20.04 to 20.10? Etc. What's different in Bookworm that would cause these issues to suddenly appear? > > 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. Sorry but I for one strongly disagree that this should be a release goal at all. It's an internal implementation detail caused by a 20 years old bug in dpkg - the maintainers of which are free to fix such bug at any time if they like (as they were in the past 20 years since this has been open and remained unaddressed), or to keep ignoring it. What is very relevant is which real consequences this does bring to the surface for users, and so far the only proven, reported and unsolved issue I have seen is the dpkg -S inconvenience, despite multiple years and an install base approaching 100% of a very popular distro like Ubuntu - of course, it is entirely possible that I simply missed them, in which case links to relevant Launchpad/bugs.d.o would be more than welcome. > > 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 Sorry, but so far it is not proven at all that we _need_ to clean up anything. Some people would very strongly like to do so, and that's a fine and legitimate opinion to hold. But it is factual that it is not objectively _needed_, otherwise Ubuntu wouldn't ship and default-usr- merged Debian installations since Buster wouldn't exist, and older-and- migrated-via-usrmerge installations since Buster wouldn't exist either. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part