On Sun, Sep 17, 2023 at 08:52:17AM +0200, Ansgar 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, ...?
/bin/perl, /bin/env, /bin/python3 did not exist in the old scheme, so there is no point in creating them now. /bin/zsh and /bin/sed existed, though. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
