Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
On Thu, 7 Sept 2023 at 09:41, Simon McVittie <smcv@debian.org> wrote:
>
> On Wed, 06 Sep 2023 at 16:51:10 -0600, Sam Hartman wrote:
> > I'd consider it a non-RC bug if someone were manually writing
> > #!/usr/bin/sh
>
> As long as our official buildds are non-merged-/usr, I would consider use
> of that path in scripts that get run at package build time to be
> potentially RC, in fact. I have tried to arrange for our official buildds
> for suites >= trixie to become merged-/usr (#1050868, #1025708) but that
> work is awaiting review.
I am aware, and we are targeting 12.2 for that (and I hope we manage
to hit the target). On the other hand, changing Lintian takes several
months usually. Policy is even slower, and moves at glacier speed, so
when I opened this yesterday I did so with the intention that by
starting now, we might get a chance to have it sorted in time for
Debian 14 (Forky is it?). Further delaying means even that target
might be missed.
Fixing the current loophole in usr-is-merged that is being used to
abuse maintainers is imperative and high priority, so I hope we will
sort out the buildd situation within a month if all goes well, and in
a couple of months at worst. I fully expect this to happen before
anybody looks at the Lintian MR, and long long before this policy
change has a chance to go anywhere.
> Until that change lands, or our official buildds for
> trixie/sid/experimental become merged-/usr some other way, encouraging
> maintainers to use interpreters that were historically in /bin via their
> /usr/bin paths is actively harmful and we should not do it. Please don't
> make the transition to merged-/usr-everywhere more contentious than it
> already is.
The intention here was not to encourage to change or switch, but to
stop bug reporters from using policy to beat maintainers. Given I am
told these sections are not normative, I am perfectly fine with
rewording in any way that achieves that objective - ie, mentioning
both paths, or none, for example.
> > >>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:
> > Luca> /bin/sh is not universally compatible with non-Linux OSes.
> >
> > I claim it is more compatible.
>
> Hard-coding "#!/bin/sh" is not compatible with every operating system,
> but it's much more widely compatible than hard-coding "#!/usr/bin/sh",
> particularly for scripts that are meant to be backportable to older
> versions of LTS distributions (notably Debian!). Even NixOS, an operating
> system that is notable for the extent to which it intentionally avoids
> using FHS paths, has made the pragmatic choice to provide /bin/sh.
>
> I would not want to encourage Debian maintainers to use
> "#!/usr/bin/env sh" for shell scripts, even though it's more broadly
> portable than assuming that /bin/sh is a POSIX shell.
> This is analogous to how we encourage (and sometimes require) Debian
> maintainers to use "#!/usr/bin/perl" and "#!/usr/bin/python3" in
> preference to indirection via "#!/usr/bin/env perl" or similar, even
> if their upstream uses "#!/usr/bin/env perl" for wider portability.
As above, the intention here is not to encourage one way or the other,
but to take the hammer away. These wordings are not normative anyway,
but they are used as if they were, and I think that's something we
want to fix regardless.
Reply to: