Hi,
On Wed, 2023-08-23 at 17:04 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
>
> Desired end state
> =================
>
> This is a very good question. I had a very constructive conversation
> with Helmut via video chat. It seems that there's a misunderstanding
> about the desired end state.
>
> My idea of a desired end state is as follows:
>
> /bin and /lib etc. remain directories (so there is no aliasing). All
> actual files are shipped in /usr. / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is
> needed
> (which is far from all of them). Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.
Cool, so we need to touch all packages shipping packages in /usr/bin to
also include a /bin symlink? Like /bin/python3 -> /usr/bin/python3?
(And yes, users use these, so they are necessary unless you want to
break working systems; if so please provide good reasons).
How do you decide when to remove a link? Is there a simple mechanism to
detect when users no longer use it?
> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.
Why should we invent again another, incompatible filesystem layout?
Is there any good technical reason to do so? One that was not discussed
already?
Sorry, I feel like we are going back ignoring any discussion in the
last years and would invite you to read what was discussed about these
approaches in previous discussions first. So far it looks like NIH
syndrome, similar to the need to invent yet another daemon readiness
protocol when systemd was the topic.
> Looking towards the future
> --------------------------
>
> It seems to me that directory aliasing will continue to be a source
> of very annoying bugs indefinitely, well after the transition is
> fully complete. In another 20 years we'll still be debugging strange
> installation breakage that will turn out to be due to directory
> aliasing.
But introducing an incompatible filesystem where we only detect that
something references files in the wrong path (as presumably only a
random subset will be in /bin) will not give any bugs?
We already *had* these bugs for several releases and found them only
after release (even before usrmerge which makes them non-bugs).
Please provide a plan how to fix these ahead of time; please be aware
that they might only occur with some hardware / configurations.
Ansgar
