Control: retitle -1 Post-/usr-merge paths for script interpreters
Simon pointed out that this bug is not yet ready to act on, which was very
helpful. Thank you. However, presumably the buildds will be /usr-merged
at some point in the not-too-distant future, and we do need to decide what
to do after that point.
I think the root problem behind this bug is that it is revealing we have
not made a decision about /bin and /usr/bin path references in Debian
after /usr-merge. Various people, myself included, made assumptions about
what the policy would be, but we never actually decided anything that I am
aware of and people's assumptions are not matching. I think we need to
talk about this directly, after which what to do with this bug will
probably become obvious.
So far as I can tell, there are three main possibilities:
(a) Although /bin and /usr/bin are merged (and likewise for the other
merged paths), Debian will continue to require (or at least recommend)
use of /bin paths for things such as /bin/sh that historically used
those paths.
(b) Since /bin and /usr/bin (and likewise for the other paths) are merged,
/bin/sh and /usr/bin/sh are equivalent. Packages can use whichever
path they want, and Debian will end up with a mix of both references.
(c) Although /bin and /lib technically work due to the aliasing, they are
deprecated and everything in Debian should stop using those paths.
All paths should point to /usr/bin and /usr/lib now.
Although Luca made a few arguments in the direction of (c), my
understanding of his current patch is that it essentially implements (b)
for script interpreters, although without encoding into Policy an explicit
decision between these three options (quite understandably because he was
trying to deal with a narrower issue). Several other people were, I
think, arguing for (a), but I'm not sure if they would continue to do so
when it's put in these terms.
Policy currently says nothing significant about this (hence most of the
text so-far discussed being informative) because, up until now, (a) was
the de facto policy. If you didn't follow (a), you would get not-found
errors and your package would have an RC bug because it wouldn't work.
If we do nothing, we'll get (b). I think that's reasonably obvious, since
there is no technical factor forcing either (a) or (c). Both paths will
work without any noticable difference, so some people will use /bin and
some people will use /usr/bin.
That said, I would rather make an explicit choice rather than decide by
default, since otherwise this seems like the kind of thing where people
are going to get conflicting advice, which is frustrating for everyone.
If someone wants to argue for (a) or (c), I think the biggest problem with
either of them is an enforcement mechanism. How are we going to check
whether packages are following the rules? Lintian and a bunch of grep
patterns is sort of an unsatisfying 90% solution, and people will ignore
it or just not use Lintian. There is also no technical reason why both
paths will not work, so people are going to get grumpy about being told
what to do and some people will view this as makework. I think any
proposal to pick (a) or (c) needs to wrestle with that.
I will also say that it will be very hard to convince me that Debian
should give Policy advice like (a) or (c) but not actually enforce it
anywhere. We have a long history to look at for how those sorts of
mandates go. Conscientious packagers who read Policy carefully follow the
rules and go to extra effort to do so, but other people will never see
that advice or not pay attention to it. That means that the effort is
mostly wasted, because no one can rely on the invariant that either (a) or
(c) is attempting to achieve. I am not a big fan of asking people to do
extra work without some clear benefit from doing that work, which mostly
requires uniformity.
One last point about this decision: although there are a few style
recommendations in it, Policy is not a style guide. The point of Policy
is to describe the things we should or must do, or at least that the
project as a whole wants to encourage, that have a concrete effect on the
quality of the distribution. I'm reluctant to add more style advice to
Policy, particularly about things that are not specific to Debian. If
we're going to require or recommend something, I think we need to have a
concrete goal in mind for what that requirement or recommendation is going
to achieve.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
