Re: DEP 17: Improve support for directory aliasing in dpkg
* Helmut Grohne <helmut@subdivi.de> [230428 09:50]:
> I think we have a misunderstanding here. As far as I understand it, the
> core idea of Luca's approach is that we move all files to their
> canonical locations and then - when nothing is left in directories such
> as /bin or /lib - there is no aliasing anymore, which is why we do not
> have to teach dpkg about aliasing and never patch it.
My understanding from following this thread (and others) is that dpkg
has a bug that can easily be triggered by a sysadmin replacing a
directory with a symlink (and some other necessary conditions that don't
happen very often), which is explicitly allowed by policy. This bug is
the one that is causing the problem with the approach that was chosen by
the people implementing usrmerge, even though they were aware of this
problem and a different approach that would have taken two release
cycles and would not have triggered this bug was considered and
rejected.
If this is correct, then Luca's approach may fix the problem for
usrmerge, but does not fix the general dpkg bug. (And, IIUC, is going
to take two _more_ release cycles to fix the problems with usrmerge as
implemented! Hmm...)
The --add-alias solution that has been suggested in this thread seems
like it would fix the general problem iff policy was changed to require
sysadmins to use it if they replaced a directory with a symlink.
I do not understand why the dpkg maintainer has rejected this solution;
it would still be a fix for the general bug after the usrmerge
transition has completed. And it would be at least one order of
magnitude more performant than scanning the filesystem for directory
symlinks.
...Marvin
Reply to: