Bug#1051371: Post-/usr-merge paths for script interpreters
> "Russ" == Russ Allbery writes: Russ> with a narrower issue). Several other people were, I think, Russ> arguing for (a), but I'm not sure if they would continue to do Russ> so when it's put in these terms. It's hard for me to express what I was advocating for in the terms you have adopted. I think you've advanced the discussion significantly by making it clear where the difficulty is, which will help me focus my argument. Russ> If someone wants to argue for (a) or (c), I think the biggest Russ> problem with either of them is an enforcement mechanism. My problem with (b) is that I value interfaces and that especially for /bin/sh I do think that /bin/sh is more portable as an interface path than /usr/bin/sh. I care a lot that we use /bin/sh in our documentation and examples (especially in policy). I care a lot that we point out that the reality of the situation is people will see other paths. At least for things traditionally in /bin I do not want to encourage those other paths, but I also don't think it is often a good use of project resources to "fix" those other paths. In some cases (for example what version of a path autoconf detects), I think that patching individual packages to detect a particular path would be net harmful. So I want to argue for (a) with no enforcement mechanism in packages. 1) Policy should encourage /bin paths for binaries traditionally in /bin. (At a minimum I'd like to see this for /bin/sh and /bin/bash). That at most makes it a minor bug if you don't follow that encouragement. 2) The examples in policy should use the standard interface paths. (This is the thing I care most about). 3) I'd like to see policy point out that /usr/bin paths will end up being used, and packages SHOULD work regardless of which path is used. I think there are some complexities here. Imagine someone writes a tool to determine if something is a shell script. If it's security sensitive, I think it is important that it work both for /bin/sh and /usr/bin/sh. If it's a syntax highlighting program and it only detects /bin/sh as a valid shell script, I'd be okay if the maintainer didn't want to fix it but instead said "fix your shell scripts if they say /usr/bin/sh." (I think the maintainer would be doing a better job if they supported both). But I would not be comfortable with a syntax highlighting tool pushing people toward /usr/bin/sh. signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
> "Russ" == Russ Allbery writes: I don't know if this needs seconds, but I reviewed all the text and it looks good. If seconds are required, I second. signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 12 Sep 2023 at 22:17:44 -0700, Russ Allbery wrote: > >> Maybe the right way to do this is just have two examples, one as the > >> default and another if you're using tmpfiles.d functionality added in a > >> specific version of systemd that's newer than the version shipped with > >> the stable version of Debian prior to the one you're targeting. Yes, I think that reads better than what I initially suggested. Thanks! The key piece of information that was missing from your previous proposal was that systemd-tmpfiles interface versions match upstream systemd version numbers. As a concrete example, if someone wants to upload an implementation other than the one from systemd, it cannot have Provides: systemd-tmpfiles (= 254) until it has at least a basic implementation of the new "X", "C+" and "--graceful" features introduced in systemd 254. > +All packages that ship ``tmpfiles.d`` configuration should declare a > +dependency on:: > + > +default-systemd-tmpfiles | systemd-tmpfiles If the package benefits from running tmpfiles.d but does not strictly require it (for example dbus-daemon, where /run/dbus/containers is needed for some optional functionality), would a Recommends or Suggests be allowed by this wording, or are we intending for this to be a mandatory hard dependency? smcv
Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
On Mon, Sep 11, 2023 at 09:25:11AM +0200, Helmut Grohne wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: wishlist > X-Debbugs-Cc: > debian-cr...@lists.debian.org,rb-gene...@lists.reproducible-builds.org > > Hi, > > more and more packages implement a technique called profile guided > optimization. The general idea is that it performs a build that is > instrumented for profiling first. It then runs a reasonable workload to > collect profiling data, which in turn is used to guide the optimizer of > a second build which is not thus instrumented. The idea is that this > second build probably is faster than a regular build. Hi! Is it possible to save the profile data to reperform the second build later ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1051371: Post-/usr-merge paths for script interpreters
On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery 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. > > 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. Russ, there is a quite related point I do not think the TC addressed directly, but I can easily be mistaken: the default PATH. It is currently defined in /etc/login.defs (unless my copy of this file is out of date): as ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games so in pratice, tools like 'which' will always favor /usr/bin over /bin $ which sh /usr/bin/sh One of the issue in the past is that reproducible build was broken because different build environment lead to different paths. We at least need to address that. Personnally, I favor keeping /bin/sh for consistency, but that is aside. Cheers, -- Bill. Imagine a large red swirl here.
