On Wed, 13 Sept 2023 at 04:48, Russ Allbery <r...@debian.org> wrote: > > 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.
While that could be said for the original revision, in my view that's not really the case for the latest that I posted? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120 So I would prefer if this was a clone rather than a retitle/repurpose. Unless I'm missing something, the changes linked above should be uncontroversial and simply remove excessively normative language in what are essentially examples that should have been taken as such - and that currently are not. So, could that be taken forward independently of the problem you define below? > 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. I think b would work out fine, but if we want to start being normative then it probably would make more sense to go for the new layout rather than the old. It would seem strange to have lived with the old layout and no rule, and suddenly add a rule for the old layout just as it has been phased out, no? But IMHO this is quite low in the priority list, as you said any of these would work just the same.
