[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 Thu, 07 Sep 2023 at 00:50:54 +0100, Luca Boccassi wrote:
> On Thu, 7 Sept 2023 at 00:45, Sam Hartman <hartmans@debian.org> wrote:
> > I.E. in the cases you adjust, I think it is already
> > not a bug, and it would be inappropriate to use existing policy language
> > to complain about which interpreter path people use.
> 
> In practice though they are used as normative, for example Lintian
> raises an error (not even a warning, an actual error).

In general, if Lintian is diagnosing paths as an error when they are
allowed by Policy (therefore not a serious bug) and work in practice
on all relevant systems (therefore not a grave bug), then the place to
change that would be Lintian, not Policy.

However, because our official buildds for trixie/sid/experimental
are still using the transitional non-merged-/usr layout at the time
of writing, it is still valuable for Lintian to care about whether
interpreters are specified with their /usr path or not: so I think Lintian
is still entirely correct to encourage #!/bin/sh over #!/usr/bin/sh,
and so on.

Also, the same version of Lintian is used to check packages targeting
any supported suite (including bookworm-backports, bookworm, and even
bullseye), and Lintian does not always have enough information to know
which suite is being targeted (consider UNRELEASED packages). bookworm
buildds are likely to remain non-merged-/usr indefinitely, to ensure we
have a working upgrade path from bullseye, so using the non-traditional
path to an interpreter (for example /usr/bin/sh or /bin/perl) is in
practice still RC for bookworm if the script might be invoked during
build. So I think it would be premature to change Lintian for this,
even after our official buildds for suites >= trixie become merged-/usr.

Using the non-traditional path to an interpreter is also *definitely*
RC for *bullseye*, because bullseye systems that were upgraded from
a sufficiently old release are non-merged-/usr unless the user has
specifically taken steps to merge it.

I think it would be appropriate to change Lintian to accept /bin/sh
and /usr/bin/sh as interchangeable after trixie is released, at which
point bullseye-backports will have been discontinued, bullseye will be
LTS-maintained, and bookworm-backports will only be receiving targeted
stable-release-suitable changes which are unlikely to regress the choice
of interpreter path.

    smcv


Reply to: