Luca Boccassi <bl...@debian.org> writes: > On Wed, 13 Sept 2023 at 04:48, Russ Allbery <r...@debian.org> wrote:
>> 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 believe it would be an error to move Policy away from explicitly saying /bin/sh as long as we have unmerged systems. For as long as we have to support unmerged systems, which includes the buildds because quite a surprising range of packages end up needing to be installed on buildds during package builds, packages must use /bin/sh and may not use /usr/bin/sh. This is not currently explicit in Policy because previously it wasn't necessary. Packages using /usr/bin/sh would simply not work, thus forcing the issue. But right now, if we were writing Policy from scratch, we would need to explicitly say that using /bin/sh is a must in order to avoid breaking the buildds, since /usr/bin/sh would appear to work locally and then potentially cause weird problems during package builds. (Ideally build failure, but a lot of strange things can happen when paths are missing during a build.) Presumably this is getting fixed in short order, so it's not worth the intermediate Policy change to add that language only to remove it again. But similarly, I don't think it's correct to relax Policy language about the /bin/sh path for as long as using /usr/bin/sh is potentially a release-critical bug. Obviously this all becomes moot as soon as the buildds are /usr-merged. > 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? The reason why this is not strange to me (which is not to say that this is my personal preference) is that previously we had a rule requiring /bin/sh enforced by a much harsher mechanism than Policy: using /usr/bin/sh would simply break. So we *did* have a de facto rule, which we implicitly dropped by doing /usr-merge, and the debate is whether to replace it with a de jure rule. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
