Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
On Wed, 15 Sep 2021 at 11:34:33 -0400, Zack Weinberg wrote:
> For the various files with a "canonical" location
> either in /usr or in /, either specified by some standard or by
> convention, and regularly referred to by absolute pathname, all
> software should continue to refer to those files by their "canonical"
> name
There are two sorts of hard-coding that are common for absolute paths,
which we should not conflate.
I think you might be primarily talking about the situation where source
code refers to an executable by its hard-coded absolute path? (As in
"#!" of a script that is installed unmodified, as opposed to being
generated from a template.)
The situation I was talking about is where a build system auto-detects
the "correct" location for some tool, such as sed or perl, and writes
that detected location into an installed file - for example reading a
template that starts with #!@PERL@ and outputting an executable script
that starts with #!/usr/bin/perl, or similar. When this happens in a
binary package system like .deb, we need to make sure that the location
that will be detected on the build system is correct for all systems
where the .deb could get installed, even if the /usr-merge status of
the build system and the installed system are different (and we need to
continue to do this as long as both merged-/usr and non-merged-/usr are
supported). Upstreams that do this auto-detection are often trying to
help the use-case of portability of a single set of source code between
OSs, but unfortunately the auto-detection is sometimes unhelpful when a
single binary package is expected to support being installed on multiple
dissimilar but equally-supported OS configurations.
In both of these cases, during the transitional period that ends when
merged-/usr becomes required, package maintainers need to make sure
(by patching the source code, or configuring the build system, or
whatever other method is most suitable) that the package they maintain
will continue to work on non-merged-/usr Debian systems. There is no
requirement that Debian packages are portable to non-Debian systems,
however.
> The most common class of such files is
> those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
> not /bin/perl, etc. I would ideally like this to be spelled out in
> Policy, as an explicit list of files that MUST be referred to without
> /usr, all others to be referred to with /usr.
A comprehensive list of executables whose paths in /{s,}bin can/should
be hard-coded seems at first glance as though it would be too large to
be particularly useful: on my x86_64 system, `apt-file search` tells
me it can see 245 files in /bin and 549 in /sbin. I'm confident that
many (most?) of those cannot be relied on to be in /bin,/sbin in all
non-Debian OSs.
As a 90% solution, it might be worthwhile to have a non-comprehensive
list of common interpreters and their canonical paths, but I think
Lintian is better-placed than Policy to do that, and it already has a list.
> As an upstream contributor to several pieces of software included in
> Debian, and as someone with an interest in ensuring that software
> developed on Linux is not *accidentally* unportable to other OSes
> under the 'Unix' umbrella, I'd like to stick an oar in
Sorry, I think portability to other Unixes is outside Debian's scope. One
of the advantages of merged /usr is that this is no longer something we
have to argue with each upstream that does not use (our idea of) the
canonical paths for everything, because both /bin and /usr/bin paths
will work.
With upstream hat on, I think this is going to be a losing battle in
general, because outside a few narrow areas that are fixed by Unix
folk history (mainly /bin/sh and /usr/bin/env), there is no portable
canonical path. For example, I regularly see merge requests to various
upstream projects saying that #!/bin/bash is not sufficiently portable
and they need to use #!/usr/bin/env bash on some OS - but in Debian,
we often prefer #!/bin/bash, to avoid packaged scripts being broken by
a locally-installed and potentially incompatible /usr/local/bin/bash.
smcv
Reply to: