Re: DEP 17: Improve support for directory aliasing in dpkg

[Helmut Grohne <helmut@subdivi.de>]

Hi Simon,

On Sat, Apr 08, 2023 at 04:06:54PM +0200, Simon Richter wrote:
> Yes, I am quite busy, but it's not forgotten. I keep adding new test cases.

Thank you for taking the time to follow up. I discarded many of your
arguments in this reply due to agreement.

> Dpkg already has defined behaviour for directory vs symlink: the directory
> wins. In principle a future version of dpkg could change that, but
> /lib/ld-linux.so.2 is just too special, we'd never want to have a package
> that actually moves it.

Your argument of the dynamic linker being too special is interesting. I
certainly agree that we must take great care at moving it, but on the
flip side I do not consider the transition complete until we reach the
point where we have moved it.

Do you actually see us coping with some aliases (e.g. the /lib one)
eternally?

> That's why I went with "this needs to be a separate mechanism."

Or do you want to say that we need a new mechanism to be able to move
such important files?

> The reason to use a control file instead of a tool would be to install the
> alias from an Essential package, so the old-school "unpack essential
> packages, then overwrite with dpkg" approach to system installation would
> work again without special-casing usrmerge in debootstrap&co.

I did not have this goal in mind, but now that you mention it, it seems
important to me. It is not clear to me though how that control file
actually gets us there. In your picture, which component is in charge of
actually creating the symbolic links on the filesystem? Can you go into
detail as to how you imagine that bootstrap without special-casing?

> > > It was suggested that the mapping could be managed via a special control
> > > file `canonical`.  Given that aliasing is not a common operation, the
> > > benefit of handling it declaratively is minor.  Beyond that, aliasing
> > > can also happen as an customization issued by an administrator.
> > > Therefore, a command line based approach is preferred.
> 
> The advantage is that it works for Essential packages, like the one shipping
> /lib/ld-linux.so.2.

In the --add-alias variant, I think we would still move the dynamic
linker to /usr and ship the /lib symlink in base-files eventually. I
admit that it is not entirely clear how such a move could be performed
safely, but that seems like a solvable problem to me. In that way, I
fail to see the control file being an advantage.

Helmut