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.
Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
On 11/09/2023 09.25, Helmut Grohne wrote: It also is unclear how it affects reproducible builds since such builds depend on the performance characteristics of the system performing the build. It is worth noting that the performance (execution time) of a build-system does not matter for profiling, so it is possible to achieve reproducible builds with PGO enabled. It is just hard. See https://build.opensuse.org/request/show/499887 linked in https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/pgo In that gzip patch we even had to hide the name of the temporary file from gzip to not get variations from a 'tolower' call that would be optimized for different amounts of upper/lower-case letters. Parallel builds and variations in ordering are also problematic, because some of the performance-counter-logic in gcc is not commutative, so running A and B calls produces different results from first calling B and then A. With all that said, in openSUSE we also have a %do_profiling value to disable PGO for gcc, python and some others, because these profiling runs are too large to make deterministic. Ciao Bernhard M.
Bug#1051371: Post-/usr-merge paths for script interpreters
Control: block 1051371 by 1050001 Hi, On Tue, 2023-09-12 at 20:48 -0700, Russ Allbery wrote: > 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. As far as I understand people wanting merged-/usr want (b) (I do). There have been people advocating (a) in this bug. However, there is a proposal by Jackson for an alternative filesystem layout based on symlink farms in consideration by the technical committee. This advocates removing compat symlinks in /bin, /sbin over time[1], thus requiring (c). The technical committee should therefore probably be aware of this policy issue in their consideration of #1050001; the resolution of which might also cover this issue (#1051371). Ansgar [1]: https://bugs.debian.org/1050001#33
Processed: Re: Bug#1051371: Post-/usr-merge paths for script interpreters
Processing control commands: > block 1051371 by 1050001 Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters 1051371 was blocked by: 1050001 1051371 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #1051371 to the same blocks previously set -- 1051371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1051371: Post-/usr-merge paths for script interpreters
Processing control commands: > block 1051371 by 1050001 Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters 1051371 was not blocked by any bugs. 1051371 was not blocking any bugs. Added blocking bug(s) of 1051371: 1050001 -- 1050001: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050001 1051371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
