Re: move to merged-usr-only?
On Thu, 21 Jan 2021 at 06:03:52 +0100, Guillem Jover wrote:
> I mentioned this before, this does not look specific to whatever
> method to do merged-/usr, instead this seems like a general dpkg
> problem related to missing fsync() on the directories during unpacks
It's great news that someone has a theory on this. I opened
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949395> for this
a while ago, but since I have no idea how to reproduce it, I wasn't able
to get anywhere.
> I don't see why this could not affect also merged-/usr-via-aliased-dirs
> systems when moving other pathnames around.
I expect it could affect any move between directories, but it's usually
only going to have a serious impact when: a file was previously in
a higher-precedence member of a search path, it is being moved to a
lower-precedence member of the same search path, and the higher-precedence
member of the search path is still searched by the loader, causing the
old file to be loaded. In other situations, the old file wastes some disk
space but usually won't be actively harmful.
Moving shared libraries from /lib/MULTIARCH to /usr/lib/MULTIARCH happens
to be a relatively frequently-done move that fits that description.
Most of our other search paths either have length 1 (so the more serious
impact won't occur because no move can take place), or add new entries
with higher precedence than old entries, for example when GTK started to
load /usr/lib/x86_64-linux-gnu/gtk-*/modules at a higher precedence than
/usr/lib/gtk-*/modules (so the more serious impact won't occur because
there is no reason why we would want to move modules from the multiarch
location to the pre-multiarch location).
I think the semantics of ldconfig make this worse for shared libraries
specifically, because even if dpkg correctly removes the SONAME
symlink in /lib for a library that has moved into /usr/lib, ldconfig
will helpfully re-create it as long as the real file exists.
(For example in the GLib case, as long as /lib/MA/libglib-2.0.so.0.4200.0
continues to exist, ldconfig will re-create /lib/MA/libglib-2.0.so.0,
with the unwanted effect of shadowing /usr/lib/MA/libglib-2.0.so.0.)
Moving executables between directories in PATH could maybe run into a
similar problem, part of which would be avoided by merged /usr (because
moving between /bin and /usr/bin, or /sbin and /usr/sbin, becomes a no-op)
but part of which is not (moving between [/usr]/bin and [/usr]/sbin could
still trigger something similar, which merged /usr would not address).
smcv
Reply to: