Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
As a Debian user I'm pleased to see the ctte taking proactive steps to
ensure that the merged-/usr transition will still allow smooth
upgrades from Debian 11 to 12 and 12 to 13.
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 regarding:
On Wed, 15 Sep 2021 at 12:39:53 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> > - §(Building packages): I almost wrote an extra paragraph about
> > how this class of bugs becomes a non-issue when merged-/usr is
> > the only supported layout - but actually it doesn't! If we
> > consider building packages while having /usr/local/bin/sed to be
> > a supported thing you can do, then we need to ensure that
> > /usr/local/bin/sed doesn't get hard-coded into the resulting
> > package, and the steps you take to make that happen are the same
> > as the steps you take to fix this class of bugs.
>
> I think that class of bugs probably does become non-RC when the
> merged-/usr transition is complete, though.
After the transition is complete, /usr/local is not the only possible
source of problems. 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, so that it remains portable to Unixes that have not and may
never undergo a /usr merge. 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.
[I agree that from Debian's perspective it makes sense for these bugs
to be RC until the transition is complete, and non-RC afterward.]
zw
Reply to: