[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters



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.

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.

> >>>>> "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.

We certainly shouldn't require shell scripts in Debian to go through
the same contortions as Autoconf-generated configure scripts to find
a POSIX shell (see `info autoconf 'Portable shell'`) because that's
unnecessary runtime and maintenance overhead on any GNU/Linux system,
any of the non-Linux ports that Debian has attempted to support in the
past, and hopefully any free or proprietary Unix that is still relevant
to Free Software authors this decade.

    smcv


Reply to: