On Tue, Aug 24, 2021 at 11:57:27AM +0200, Simon Richter wrote: > Hi, > > On 8/24/21 2:48 AM, Theodore Ts'o wrote: > > > So.... in theory, if we had a program which looked for the top-level > > symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist, > > scans dpkg database is scanned looking for of the form > > /{bin,lib,sbin}/$1, and updates them with /usr/{bin,lib,sbin}/$1, and > > then in the future, if dpkg sees the top-level symlink, canonicalizes > > any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a > > fallback searching for /{bin,lib,sbin}/$1 in the file system, this > > would solve the problem. > > Yes. To apply the transformation, this would likely have to happen in the > dpkg package itself, so the one-time transformation is applied only when > dpkg can maintain the workaround from that point on.
Sure, since we're talking about dpkg database surgery, it's better that the sources of such a program be located in the dpkg sources, and regardless of who does the work, the dpkg maintainers should be involved in the code review of any such change. > That is the half that is missing from my proposal, as I was focusing on how > to transition non-usrmerged systems from within dpkg. I've been more focused on the usrmerged systems since nearly all of my personal systems are already usrmerged, since I tend to reinstall my systems whenver I upgrade my hardware, and deboostrap has installing systems with the usrmerge top-level symlinks since Buster. Furthermore, people have been arguing strenuously that the possibility of file loss is real for these usrmerged systems, so fixing this seemed to be high priority, regardless of how many systems use the usrmerge setup. So protecting against lost files was higher priority in my mind, whether the people arguing that it's rare because Ubuntu users having been losing files, or not, I accept the argument that if it can happen (and you've demonstrated via adversarial test cases that it *can*), we should fix that bug, whether it's considered an RC bug or not. (Although my personal belief is that we should be a lot more open to fixing less critical bugs in stable releases, so if we have a fix, I'd be all for rolling it out early to Bullseye regardless of whether it's considered "RC" or not.) > > Let's ignore how we would deploy this helper program and the update > > dpkg from a stable upgrade perspective, but in terms of preventing > > potential problems during the testing window, getting an update to > > dpkg which included the database fixup program and which ran from the > > maintainer script would be a potential solution path. > > Yes-ish. We'd also need to make sure that installing the usrmerge package > after that dpkg upgrade does not make things inconsistent again, so it would > make sense for the dpkg source package to provide a "usrmerge" package that > is well integrated, and for dpkg to conflict with older versions of > usrmerge. I'm less worried about whether usrmerge is part of dpkg or not, since most of my usrmerged systems are due to them being reinstalled since Debian Buster has been around, and the definition of usrmerged is relatively well understood (symlinks for /{bin,lib,sbin} to /usr/{bin,lib,sbin}). But it wouldn't hurt for dpkg to provide its own "usrmerge" functionality, and I certainly wouldn't argue against it. > > Furthermore, if dpkg knew to always canonicalize filenames from > > /{bin,lib,sbin}/XXX to /usr/{bin,lib,sbin}/XXX when adding to the > > database, and when it looked for files in the file system looked first > > in /usr/{bin,lib,sbin}/XXX, with a fallback to /usr/{bin,lib,sbin}/XXX > > the file names in the package would not need to change all, since all > > of the magic fixup work would be happening inside dpkg. > > Yes. In an ideal world, we wouldn't hardcode the list of symlinks in dpkg > though, that's why I proposed shipping symlinks in base-files and having > dpkg recognize the symlink-vs-directory conflict as intent to move a > filesystem tree around. That's certainly the more general solution, although again, I think the definition of usrmerge is well understood, especially since Debian has been on the trailing edge of the usrmerge transition across the Linux ecosystem, and so the high priority should be for fixing the specific case of moving the contents to /{bin,lib,sbin} to /usr/{bin,lib,sbin} and leaving symlinks behind for the directories. If we want to support people who want to say, move /usr/bin to /u1/bin, and /usr/lib to /u2/lib, or even /usr/lib/X11 to /funky/dir/X11, great! Personally, I wouldn't consider that a high priority item on the requirements list, though, unless it comes essentially for free. Cheers, - Ted