Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms)
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
Reply to: