Bug#1051371: Post-/usr-merge paths for script interpreters
On Sun, Sep 17, 2023 at 08:52:17AM +0200, Ansgar wrote:
> > Control: unblock 1051371 by 1050001
> >
> > Ansgar <ansgar@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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: