Hi, On Sat, 2023-09-16 at 12:58 -0700, Russ Allbery wrote: > Control: unblock 1051371 by 1050001 > > Ansgar <ans...@43-1.org> writes: > > > However, there is a proposal by Jackson for an alternative filesystem > > layout based on symlink farms in consideration by the technical > > committee. This advocates removing compat symlinks in /bin, /sbin over > > time[1], thus requiring (c). > > This is not a correct summary of Ian's proposal. In the message that you > linked, Ian says: > > /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. > > I am absolutely certain that Ian would consider /bin/sh to be one of the > programs for which a compatibility symlink is needed, and one of the > remaining handful of links that would exist indefinitely into the future. > Indeed, he mentions /bin/sh explicitly later in that message.
But the subject of this issue talks about "script interpreters", not just `/bin/sh` (which I guess is safe to assume would be one of the "handful"). It is unclear what files the Jackson symlink farm proposal would leave in /bin. Would /bin/python3 stay? Or would it stay first, but dropped at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? As far as I understand most compat symlinks should eventually be dropped (but which is unclear). Therefore doing (c) is safe, but anything else might use symlinks that eventually disappear. (And really: what about calling /sbin/ifconfig, ... as well? Here (c) is again the only safe solution with the Jackson symlink farming proposal.) It was asked to clarify the plan for this multiple times, sadly the proposers of the newly proposed filesystem layout have refused to give any answer so far. Ansgar
