Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Sean Whitton writes: > We have two seconded solutions, so you and I should perhaps break the > tie. I prefer the Bill's 'Autobuild: no' solution as the more > conservative change: we only have data about packages that are currently > autobuilt, not those that aren't, so we might be making those buggy if > we just ban network access for all non-free packages. How about you? Yup, let's go with Bill's change since it's a bit more conservative. I think it accomplishes the same goal. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Philipp Kern writes: > On 04.04.24 20:51, Bill Allombert wrote: >> I still think we should allow Autobuild: no as an escape hatch. If we >> want to require non-free package to be autobuildable, we should be more >> explicit about it (and probably require more feedback from >> debian-devel). > There is no requirement for non-free to be autobuildable today. This > change also does not introduce this, except for everything that is to be > built on official builders to not require network access. I think Bill's point is that the section of Policy being changed here isn't only for autobuilt packages. It sets general requirements for all Debian packages, including non-free packages that are never autobuilt, and therefore arguably prohibits network use during the build of a non-free package that was never intended to build on the autobuilders, which is a bit outside the scope of the original motivation for this change. (I didn't understand that point at first.) I'm not sure what I think about that. We have a general escape hatch already for non-free packages in Policy 2.2.3 that says they may not fully comply with Policy, which may be sufficient. Builds that use the network seem like a bad idea even in non-free packages because it means we may not be able to rebuild them since all of the relevant data is not in the Debian source package. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Tobias Frost writes: > On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: >> Thanks Philipp. Following that result, please find a patch proposal: >> >> --- a/policy/ch-source.rst >> +++ b/policy/ch-source.rst >> @@ -338,9 +338,9 @@ >> For example, the build target should pass ``--disable-silent-rules`` >> to any configure scripts. See also :ref:`s-binaries`. >> >> -For packages in the main archive, required targets must not attempt >> -network access, except, via the loopback interface, to services on the >> -build host that have been started by the build. >> +Required targets must not attempt network access, except, via the >> +loopback interface, to services on the build host that have been started >> +by the build. >> >> Required targets must not attempt to write outside of the unpacked >> source package tree. There are two exceptions. Firstly, the binary > LGTM, Seconded. Also looks good to me. Seconded. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Josh Triplett writes: > Nonetheless, if the Policy editors are opposed to documenting something > despite it being collectively known to be the case, and do not feel that > any possible wording change would change that position, then I will not > push for it further. I have already suggested a wording change that I would be happy to review and that I think would be much more likely to accomplish your goals. Document the other way of doing things that you would like Policy to mention. It doesn't have to be long; in many cases, one paragraph with some man page references would be sufficient to get people pointed in the right direction. In an ideal world, I think people *should* prefer to do things in one of the ways that Policy documents doing them, even if other ways of doing them would be acceptable. That's how we get a more consistent distribution. This requires documenting our preferences, which seems like a good thing all around. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Josh Triplett writes: > Mostly, recent discussions in various places regarding whether packages > are required to use *cron* to run periodic jobs. Policy says what > packages must do if they install a cronjob, but that itself does not > mandate the use of cron specifically. It seemed worth explicitly stating > the understood-but-unwritten interpretation that having Policy about XYZ > does not mandate that packages use XYZ. There is a near-universal human tendency to argue with the medium if one disagrees with the message. As part of the old saying among lawyers, often attributed to Carl Sandburg, goes: "If the facts are against you, argue the law. If the law is against you, argue the facts." I don't think these discussions were truly about the wording of Policy, and I don't think changing the wording of Policy in the way you propose would have changed those discussions. There is no magic wording of Policy that, if we get all of the sentences just right, will cause the project disagreement over the appropriate role of systemd to somehow melt away. It is possible that someone unaware of the long-standing project debates about systemd and timers and so forth (I take it on faith that somehow such people still exist) might, upon reading Policy and seeing only one description of how to handle periodic tasks, assume that's the only one that Debian supports. I don't think the solution to that problem is to add a generic statement elsewhere in Policy that they are neither likely to read nor likely to connect to the problem they're trying to solve. I think a better solution is to document the other way of doing things in Policy. Then we can argue about whether Policy should recommend one method over another, which is the real heart of the disagreement that at some point we need to confront. (I know, I know, I'm one to talk given that I dropped all my Policy work on the floor and disappeared for six months. But still, I would give myself the same advice.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1057057: debian-policy: Please make Checksums-Sha1 optional
Dimitri John Ledkov writes: > Dak currently requires Checksums-Sha1, but I am happy to facilitate in > patching dak to make Checksums-Sha1 optional if this bug report is > accepted. The field is documented as mandatory precisely because DAK requires it, which makes it mandatory for Debian packages. As soon as DAK doesn't require it, I'm happy to make it optional (and indeed it would arguably be a bug in Policy if it's optional in the archive but Policy claims it's mandatory). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Niels Thykier writes: > Russ Allbery: >> Ooo, this is a great framing of the problem. I have a lot of thoughts >> about this. Unfortunately, I'm not sure if they're actionable thoughts >> since my grand vision requires someone to sit down and do some serious >> Policy restructuring and produce a radically different document. But >> maybe if I write them all down and enough people feel similarly, it >> would be worth doing. I would love to work on this, I am just afraid >> that it is the sort of project that I would start and never finish and >> thus never accomplish anything of use. > Indeed, it is definitely the thing I would personally prefer to > pre-align on before adventuring on something of this scale myself (were > I in your shoes), so I totally feel your concern about actionability. I do to some extent want people to encourage me to work on this if they think it would be awesome, since people being happy with it would be what would make all the work worthwhile (although I will probably also need help). :) > Interesting choice with the mixing. I was of the understanding that the > idea was one should try to avoid mixing documentation styles according > to Divio. Admittedly, I find it hard to fully stick to exactly one type > of style, so I would be happy if I had just overlooked the "advice on > mixing". So, I have to admit that I have not read Divio in detail although I have been pointed at it many times and have had the high-level concepts explained to me. I've read bits and pieces, but I'm not sure what it says about mixing. But in terms of what makes an effective Policy document, I think a general structure of an explanation section introducing a part of packaging followed by how-to sections for the underlying tasks would work. > As for the content: The "How-to" style would make sense for the target > audience. I am less clear if all of these headlines makes up a "Policy" > as they sounds like something you could find in a "Debian Packaging 101" > guide. I think that about a quarter of Policy currently is already how-to text. For example, look at Policy 3.4: https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions This is a disguised how-to document on how to write a good package description. There's a ton of stuff in Policy like this. What distinguishes it from a Debian Packaging 101 guide is that the how-to goes into *way* more depth than a 101 guide: edge cases, exceptions, advanced bits of packaging, etc. The main problem from the perspective of helping the typical packager, is that this is mixed in with oodles of advice that is irrelevant to anyone except debhelper maintainers. To take another short example, look at the section on symbolic links: https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links Half of that section is a specification for the packaging helper, which will fix symbolic links to follow those rules. The rest is sort of a how-to (mixed in with some basic shell command advice). > Side question: Does Policy add anything on the specification for > `symbols` and `shlibs` files as a reference document that is not covered > by dpkg's documentation for these formats? I assume the "symbols guide" > (on /when/ to use symbols and when not too) would go in the previous > section. Well, one can read the two side-by-side and see, and I'm biased as the person who wrote it, but I think it does. Policy duplicates dpkg documentation quite a lot, so this is a question worth asking, but I do think Policy has a good answer. The value that Policy adds over the dpkg documentation generally falls into three categories: 1. Policy is much more opinionated about what features supported by dpkg should be used in packages and how they should be used. There are sometimes things dpkg *can* do that we don't do. A bunch of this is how-to, but I think some of this is reference. 2. Policy is sometimes a lot more verbose and offers worked examples, and sometimes benefits from the additional formatting tools available in Sphinx. This could be imported into the dpkg documentation to some extent, of course, but as it stands I think there's value there. 3. dpkg documentation has to cover the complete operation of dpkg, whereas Policy, even in reference sections and packaging helper sections, should only need to cover the surface area that's visible to packaging at the lowest level. I agree that this is a source of some duplication of effort, although in my experience it's not the part that takes the most time. (But I haven't written triggers or multiarch documentation for Policy yet, so maybe it's part of the problem.) > What is it you would see go into this section [packaging helper > specification] that is not the previous section? Literally everything in Po
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
ely free to just make changes without going through a very formal process as long as those changes reflect reality. This is, by nature, going to be incomplete and possibly out of date, but I do think the project should have *somewhere* outside of any specific package where people can write down the details of, oh, the other options to Rules-Requires-Root that we aren't currently using. But we would stick a lot of disclaimers on it and make it clear that this is internals that only 10-20 people really need to know about. I don't know if we can get here, but personally I think it would be a massive improvement over where we are now, even if we spend the next ten years sorting out structural problems with how we moved things around. But it's a *ton* of work, so realistically it's never going to happen unless it excites other people as much as it does me. Anyway, that's a very long-winded answer to Niels's question. I think Policy should primarily have an audience of packagers, including packagers who need to coordinate cross-package integrations, secondarily have an audience of tool makers who need a reference manual for Debian's file formats and integrations, and then have a deprioritized tertiary audience of toolchain maintainers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Alexandre Detiste writes: > The ugly magic behind the curtain: > ls /usr/libexec/cruft/ -1 > LOGROTATE -> that parses these for path > SERVICES -> added today reading this discussion, it reads > CacheDirectory= & StateDirectory= from *.service > TMPFILES -> that parses these for path > This whole thing, while being already usefull & used, > is more like a mockup of what could be a "perfect" dpkg. > These tiny shell scripts could be converted into something else > that plugs into dpkg ... for example tiny .so plugins that answer > which package own which dynamic file ? > (for runtime evaluation, other possibility is debhelper magic at > compile-time that generate a list of possible files) Based on previous discussion with Guillem, I think the direction Guillem is headed is something like adding a new member (or field in another member) to the deb format that holds a list of volatile files that the package considers itself responsible for. I think I agree with Guillem's position (at least as I understand it) that it doesn't make sense for dpkg to parse other files to populate that list. That can very easily be handled outside of dpkg. So the idea would be that the package would install tmpfiles.d files, service units, and similar files as normal, and then debhelper would parse those files, extract the list of paths that they manage, and use that to write a control file or the like that dpkg consumes to register those files. If I'm correct about that design, an intermediate step in that direction from where cruft is today would be to add that logic to debhelper and then have debhelper ship that database in the package in /usr/share/cruft/ or some similar directory, and then cruft could just consume that database of registered paths to get attribution information until such time as that can move into dpkg. This design is just off the top of my head, and I'm probably missing some problems and some details. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Bill Allombert writes: > As I said, filling the caches in /var/cache. For that they need to exist > with correct ownership and permissions. Sorry, I think I saw that and then edited my message more and lost it again. That use case makes sense to me, and without the directory already present, you have to know what directory to create and you have to get the ownership and permissions correct. But there's a couple of reasons why I don't think that's a problem: 1. Installing the package creates the directories since it invokes systemd-tmpfiles via postinst, so the directory will normally be there with correct ownership and permissions. The only case where it wouldn't be is in cases where the packages were installed without running postinst, which feels like an unusual use case. 2. Presumably you would be copying these caches from another system, which will normally have the directory with correct ownership and permissions. This isn't necessarily true if you're mixing versions of Debian, of course, but in that case it's not clear the cache format will be correct either. Also, you need to get the ownership and permissions of the files right, which the directory structure doesn't necessarily help you with, and if you're copying that over already, the same mechanism can handle the ownership and permissions of the parent directory. So, by definition any directory that's shipped in the deb cannot have dynamic ownership, which also limits the range of permissions it could have. > even populate /var/www with your website, etc. /var/www is a whole separate problem that I agree has not yet been addressed and would need to be. We've known that /var/www is weird for a while (we have a special exception in the FHS for it because it's breaking the FHS file system layout rules), and there have been a few attempts to handle it some other way, but none of them so far have been successful. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
m very bad at this and have to be reminded repeatedly: stop arguing with people about specifics and use that energy to write down a design with a justification. It will make the arguments much less annoying and repetitive, because a lot of the repetition is because everyone else is sadly incapable of reading your mind and doesn't understand what you are assuming is well-known. > We are working on that. This means that tmpfiles.d would be able to both > create the files/dirs when needed, and remove them when unneeded, ie on > purge - as far as I can tell, that would be the only useful thing that a > dpkg integration would provide. dpkg -S is the most useful feature this supports for me personally (and some related things, such as cruft-finding). More generally, dropping directories that are currently registered with dpkg from dpkg's database is a regression. I think it's a minor regression, but I also think it's an avoidable regression; the amount of work required to maintain an entry in dpkg's database for empty directories that currently can be shipped in the deb is not very high. > I am pretty sure running checksums on local variable data would be a > pretty useless exercise given, well, it's variable. Empty directories don't have checksums, so I don't think this is relevant to this discussion. I'm only talking about empty directories, not files. Packages shipping files in /var is a different problem; there are some packages that do that currently for various reasons (/var/www for web servers comes to mind), and I think we should probably phase that out whether or not we do factory reset and am not intending to entrench that here, but I think it's a different Policy change. > On the contrary I suspect it would break things or at the very least get > in the way, as explained above. Of course I haven't tested this as we > aren't there yet, so can't be 100% sure. But from what I've seen from > some experiments, expectations around /var being fixed and > package-managed is already creating some headaches, and requiring > workarounds. Specifics! Specifics! My kingdom for specifics! :) Bug numbers for these headaches would be helpful, or detailed descriptions, or *something*. You're giving me nothing to work with here, which means that I'm likely to go forward with requiring some of these empty directories be registered with dpkg because that's the less invasive change and avoids a regression. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Ansgar writes: > But the subject of this issue talks about "script interpreters", not > just `/bin/sh` (which I guess is safe to assume would be one of the > "handful"). > It is unclear what files the Jackson symlink farm proposal would leave > in /bin. Would /bin/python3 stay? Or would it stay first, but dropped > at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? Oh, okay, I see what you're syaing now. This is a bit beyond the scope of the areas of Policy touched by Luca's proposal, but I can see why it would indeed arise under Ian's proposal. We've introduced new /bin interfaces for every binary in /usr/bin, and if we went down that path we'd remove most of those interfaces again. That is indeed an argument for (c) for *most* things, just not the areas touched by this diff (with the possible exception of /bin/csh; I'm not sure if that would qualify for an exception or not, these days). So yes, I agree that the resolution of this bug would significantly affect what we want to say in Policy about /usr-merge in general, even if not what we say about /bin/sh. I still don't feel like we need to wait for the TC bug to be resolved, since there is a standing TC decision to make /bin a symlink to /usr/bin and we can always change our wording later if that decision changes, but we need to wait for the buildd /usr-merge anyway, so either way I don't think we're ready to merge patches for this bug right now. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Bill Allombert writes: > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote: >> On Sep 17, Russ Allbery wrote: >>> (I am a little confused by this wording, but I think what you're >>> saying is that /usr is encrypted and read-only, and /var is recreated >>> on each boot. That at least is my understanding of the pattern that >>> you're trying to enable.) >> The general idea is to be able to create /var on the first boot. > Does not that would break users expectation that the system image > contains /var before the first boot ? > A lot of things in /var are caches that are mostly instance-independent > and can be prefilled, but for that, users expect a minimal directory > hierarchy to be present before first boot. Not that I think we're particularly close to achieving this design currently (and to be clear we haven't decided we're working towards this yet), but while I understand why a user would have that expectation today, I'm not sure why it would practically matter. If all of that directory structure appears on first boot, and no static data is stored in /var, what use case requires the directory structure already exist in /var before the first boot? I think you're thinking of cases where the user puts data into /var and expects it to be used by the system after boot, but configuration data would go into /etc, so I'm not sure what data that would be. Also, I think that scenario would still work. My understanding of the design is that /var isn't tmpfs; while there's no precreated directory structure, the user could still make one if they wanted. There wouldn't be the guide of existing empty directories, but this is a fairly sophisticated use case, IMO. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#915583: debian sphinx styling: second attempt
RL writes: > http://stephane.yaal.fr/tmp/release-notes/issues.html#grub-no-longer-runs-os-prober-by-default > the '# dpkg-reconfigure ' is shown as a shell-comment, but is > meant to be a command-to-run-as-root (i remember this being discussed on > the previous version on the release-notes list, and i thought someone > had posted a way to fix it?) The sphinx-prompt extension plus using: .. prompt:: bash :prompts: # dpkg-reconfigure will fix this, with the added bonus of removing the # prompt from the text that is selected when the user cuts and pastes, so they can cut and paste just the command. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?
Daniel Gröber writes: > Ultimately I'm just concerned about the UX aspects of admins suddenly > having to go hunting for config files all over their system when > packages start implementing this config-in-/usr business en mass. I think the expectation is that you read the documentation of the package that you're configuring, just as if the defaults were all hard-coded in the binary. I realize that some people *prefer* to have all of the configuration of a package documented in comments or settings in a template file installed into /etc, but this has never been something we *required*, just a convention that some packages follow and some do not. > I don't really mind if we go that way but then policy needs to be > updated and some convention or mechanism[1] put in place to make working > with config by hand as easy as it's been in the past, but that work is > on the devs pushing the project in that direction. This is a change that is mostly happening in the upstream development of some packages, so I think your attribution of cause may not be entirely accurate. People are adapting Debian packages to a configuration model that started in other distributions and has been adopted by the upstreams of those packages, and some of them are also advocating for this configuration practice as a good idea, but the push of Debian in that direction would be happening regardless of the opinions of Debian maintainers about this configuration method. Some of our upstreams are adopting this and it's highly unlikely that we would maintain local patches to undo that change. I'm not sure how much of the documentation belongs in Policy, since this is really user-facing documentation, which is entirely outside the remit of Policy. Policy is only about packaging; we don't expect users of Debian systems to read it. But I'd be happy to review a patch that updated the Policy wording of configuration files to make it clear that "configuration files" only refers to the files edited by administrators in the course of configuring the system, not to wherever the read-only configuration defaults may be stored. Obviously if someone wants to write better tools to manage these configuration files, that would be great, but that's outside the scope of this list, and I am dubious that we would refuse to update to newer upstream versions of our packages until someone writes such a tool. We are part of a larger ecosystem, and some critical components of that ecosystem are moving in this direction regardless of what we do. > On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote: >> Configuration file has a very specific meaning in Policy: it's a file >> that the local system administrator changes in order to configure the >> software. > Sorry, I don't buy that. Policy is kind enough to have an explicit > definition for what it means by "configuration file" in > 10.7.1. Definitions: >> configuration file >> >> A file that affects the operation of a program, or provides site- or >> host-specific information, or otherwise customizes the behavior of a >> program. > "A file that affects the operation of a program" pretty clear cut to > mean exactly the type of files at issue here. I understand that this is not what you want this part of Policy to mean, but a "configuration file" in Policy has always been the file that you edit to change the operation of the program. It is not a *requirement* that every file shipping with the package that contains configuration defaults be installed in /etc. Given the number of packages that hard-code configuration defaults into the binary and put them nowhere else on the file system at all, this would not be possible. It is *common* for a package to install a configuration file that has some or all of the defaults, as a template for local administrators to modify, but there have always been packages that do not do this, and other packages that do this for some configuration files and not others. There have always been some packages that put the defaults or the configuration template elsewhere, whether that be /usr/share/doc//examples or hard-coded into some binary. Packages that use this "empty default /etc" configuration approach do not ship *any* configuration files under the Policy definition. They only ship binaries and data files for those binaries that contain default settings. Those files are not modifiable and are not configuration files in the Policy sense. From a Policy perspective, they're exactly like the files installed in /usr/share/pam-configs, /usr/share/doc-base, or /usr/share/applications, which are also files that affect the operation of a program. I agree that the wording in Policy could be clearer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Aside from more practical considerations, shipping /var content in > packages is problematic because it's supposed to be local variable data, > that can be removed without breaking a system. Unless I'm missing something, including the directory in the deb won't make any difference here. dpkg won't break if a directory that was included in the package is deleted. It would show as an inconsistency if someone checked the file system against the dpkg database, but as soon as systemd-tmpfiles runs, it will create the directory again and fix the inconsistency, so I don't see what problems that would create. > More practically, one of the purposes of the hermetic-usr pattern is to > allow several modernizations. The easiest one to achieve is to create > /var/ on firstboot, and encrypt it against the tpm, so that it can be > enabled by default, always, so we can't have packages ship and expect > content in /var from their packages. (I am a little confused by this wording, but I think what you're saying is that /usr is encrypted and read-only, and /var is recreated on each boot. That at least is my understanding of the pattern that you're trying to enable.) Here too, I don't see how including an empty directory in /var in the deb will make any difference here. When you create such a system, you would delete /var, so it wouldn't matter if packages created files in there (and in fact, under every proposal in this bug, installing packages *would* create files there, since systemd-tmpfiles would be invoked by the maintainer scripts anyway). > On top of that, as you mentioned already things will inevitably get out > of sync, and one will have to duplicate everything. One would need to duplicate empty directories in /var (that don't have dynamic ownership). I'm dubious that's a significant burden (it's two or three lines in debian/rules), but if it is, one could even automate this in debhelper by parsing tmpfiles.d if one really wanted to. The main thing that could get out of sync is the ownership, which is indeed not ideal, but I'm also not sure it's going to cause major problems even if people do get it wrong. I was trying to remember if dpkg changes directory (as opposed to file) ownership if it sees a directory owned by an unexpected user. I kind of think it doesn't, but I'm not sure about that. The benefit we gain from this is attribution of the directories in the dpkg database, which is useful (although I understand that one can argue about how useful). So... I think the answer to my question of whether this will interfere with your use case is no? I understand that you don't want to do it, and expected that, and that opinion is important for the discussion, but I'm also trying to figure out if it will *break* anything. > And if dpkg gets the ability to read tmpfiles.d - then that's great, > and even more reasons not to change policy for something that would > only be a temporary stop-gap. I'm not going to assume that this is going to happen on any particular time scale. dpkg has to gain a mechanism for registering transient files first, which in my understanding depends on other significant dpkg architectural work. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Simon McVittie writes: > 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. Yeah, I had missed that, thank you. I think that's now captured. > 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? I'm not sure it's going to make a lot of difference in practice, since I think it will be hard to end up with a system that doesn't have a systemd-tmpfiles implementation installed, but I agree that in theory this is too strong. I'll try to come up with a rewording that allows for the possibility of Recommends or Suggests. Maybe just a parenthetical that says or Recommends or Suggests if this more accurately fits the nature of the dependency? I think apart from this and resolving whether to add empty directories into the deb, the remaining issue before we can merge this is to make sure that the sysvinit maintainers are okay with adding the requirement that the init system invoke a systemd-tmpfiles implementation periodically. As I would expect, the systemd-standalone-tmpfiles package only provides the binary, not any init system integration. Does anyone know if that integration has already been done to invoke systemd-tmpfiles during boot on systems using sysvinit? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#915583: debian sphinx styling: second attempt
Stéphane Blondon writes: > I've done a new version. It's based on 'sphinx_rtd_theme' theme. So, to > build the site, the package 'python3-sphinx-rtd-theme' requires to be > added to dependencies. A new file 'debian.css' is specific to set some > colors and renderings. > Reusing 'Read the docs' theme allows to have a responsive design > automatically. > The theme could be modified more but it could be considered as a first > step which is already usable. > There are temporary demos available: > - for debian-policy: http://stephane.yaal.fr/tmp/policy/ > - for (draft sphinx) release-notes: > http://stephane.yaal.fr/tmp/release-notes/ > What do you think about it? Hi Stéphane, Thank you so much for this! I poked around a little bit on your draft render of Policy and personally I'm quite happy with it. The sidebar management with small screens seemed to work for me and is definitely better that what we have right now. I would encourage others to also take a look and provide feedback. My inclination is to merge this in a future release of Policy. The one minor thing that I noticed was that the version number of Policy in the left sidebar at the top is very difficult to read because it's almost the same color as the background. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Bill Allombert writes: > 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. I believe the reproducible build problem specifically will be largely fixed by /usr-merging the buildds so that they look like all other Debian systems. I suspect the problems that you ran into in the past were precisely because some systems on which the package was built were /usr-merged and others were not. But you make a good point that just because the /bin and /usr/bin paths both work does not mean that package build systems can pick randomly between them, since that undermines build reproducibility. They need to pick one or the other consistently. I do think packages should be allowed to do a PATH search, and it's up to the people doing a reproducible build to make sure the PATH stays consistent from one build to the next. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
nt 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. I think this is the only part of your proposal that I have qualms about, because I agree with Luca that people would use such encouragement to file bugs about it, and I'm not sure we want to encourage those bugs. It may not matter a lot because the bugs will probably exist anyway, but I know that putting things in Policy can sometimes raise the temperature of even minor bugs. I'd be happy to make some sort of statement in the section about shell scripts that /bin/sh and /bin/bash are the traditional paths and will work even if the script is copied to some non-Debian system, but I'm reluctant to issue Policy advice that one therefore should use those paths. But I could be convinced as long as it's just advice, not a should. (But, again, Policy is not a style guide.) > 2) The examples in policy should use the standard interface paths. > (This is the thing I care most about). I agree with this and I'm not seeing any disagreement in the discussion so far. > 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. This is the thing that I care the most about and would like to say explicitly somewhere in Policy, even though that's beyond the scope of Luca's original report. I don't think Policy says anything about /usr-merge at all right now, and once the buildds are merged and all Debian systems relevant to unstable development are /usr-merged, we probably should. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Control: unblock 1051371 by 1050001 Ansgar writes: > 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). This is not a correct summary of Ian's proposal. In the message that you linked, Ian says: /bin and /lib etc. remain directories (so there is no aliasing). All actual files are shipped in /usr. / contains compatibility symlinks pointing into /usr, for those files/APIs/programs where this is needed (which is far from all of them). Eventualloy, over time, the set of compatibility links is reduced to a mere handful. I am absolutely certain that Ian would consider /bin/sh to be one of the programs for which a compatibility symlink is needed, and one of the remaining handful of links that would exist indefinitely into the future. Indeed, he mentions /bin/sh explicitly later in that message. Given that, I believe Ian's proposal is orthogonal to this bug. For /bin/sh and /usr/bin/sh, it would create the same aliasing and thus would create the same question about how to talk about those paths in Policy. I therefore don't think resolution of this bug blocks on the TC bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Luca Boccassi writes: > On Wed, 13 Sept 2023 at 04:48, Russ Allbery 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/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Guillem Jover writes: > Not shipping these empty directories in the .deb seems like a regression > or a disservice to me. Even for things that might get deleted because > things like our policy or the FHS allows for it (say stuff under > /var/cache), as «dpkg --verify» can be useful. Because of course, these > in addition, can be defined via tmpfiles.d, so that they can possibly be > recreated if needed (until dpkg provides its own interfaces to do that). Luca, are there any drawbacks for your purposes in both shipping the directories in the deb *and* defining them with tmpfiles.d for those cases where it is possible to ship them in the deb (no dynamic owner or group, for instance)? At first glance, it feels like this should be fine, since tmpfiles.d will recreate the directories and dpkg will then be happy with them. It does potentially create problems if dpkg and tmpfiles.d have different ideas about what the ownership or permissions of the directories should be, but at present I don't think such conflicts would create a lot of practical problems (tmpfiles.d should essentialy always win), so I think it's a fairly minor point. It's a bit more complicated to specify in Policy because it's not possible to include the directory in the deb file in cases where it needs to have ownership set based on users or groups created dynamically by the maintainer scripts, but hopefully not overly complicated. This has the valuable benefit, as Guillem points out, of retaining dpkg database awareness of the association between that directory and a package until such time as dpkg is aware of files defined in tmpfiles.d (directly or indirectly via debhelper magic to register the tmpfiles.d targets with a new dpkg dynamic file database; the latter is my guess about where we're headed based on previous discussions). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?
Daniel Gröber writes: >> Any configuration files created or used by your package must reside >> in /etc. > Pretty clear cut in my reading, however this was promptly shot down by > Bastian with the justification: Configuration file has a very specific meaning in Policy: it's a file that the local system administrator changes in order to configure the software. If the file is not intended to be modified to configure the software, it's not a configuration file, even if it contains configuration defaults. See: https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files although it doesn't make this as clear as it should be because it was written before split configurations became common. That's because the main point of distinguishing configuration files (in addition to collecting them in /etc for the use of things like etckeeper) is to ensure that we handle the modifications correctly, don't lose them during upgrades, etc. Static files that aren't modified by the local administrator don't need that special handling. Having the configuration *defaults* exist as a static file on disk in /usr/lib isn't really that different than having the configuration defaults exist hard-coded into the binary, which has been common for many years. Either way, what Debian requires is that the defaults be modified by putting files into /etc, so as long as that continues to be true, this is satisfying Debian's configuration requirement. This isn't that different than long-standing UNIX precedent, as seen in packages such as postfix or INN or any number of other programs that support configuration files in /etc but have a large number of hard-coded defaults that apply if those files are missing or don't set that option. I should say explicitly that none of this addresses the *preference* argument between people who prefer to have the defaults in /usr and overrides in /etc, and people who prefer to have all of the settings in /etc so that they are readily visible for modification. Some people prefer one, some people prefer the other, and both sides feel strongly about it and probably won't convince the other side. But this conflict has existed for essentially forever in the form of defaults that are hard-coded into the binary and not expressed in the sample configuration file, so it's not really a new conflict, and I think it's more transparent to have defaults in a separate file in /usr than hard-coded into a compiled binary. I do understand why folks who prefer the "all settings in one modifyable file in /etc" are annoyed when packages move to the split configuration model with a file of defaults in /usr, but it's not something that Policy requires one way or the other and there are vigorous advocates of both methods. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Russ Allbery writes: > Russ Allbery writes: >> 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. > Here's an updated version with that change plus some other minor fixes. Er, right, helps to rebase first. Here's the actual patch. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..fa3e5be 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories in ``/var`` or ``/etc``, or +symlinks or files with trivial content in ``/var``, to implement their +functionality. Examples include directories under ``/var/cache`` that are +writable by the package as cache areas, an initially-empty directory in +``/etc`` intended for local overrides added by the local system +administrator, or a file in ``/var`` that should default to a symlink +elsewhere on the system but may be changed later. + +Rather than include these symlinks, files, or directories in the binary +package or create them in package maintainer scripts, packages should use +the ``tmpfiles.d`` mechanism to specify the files and directories that +should be created. This allows associating these files and directories +with specific packages (not currently possible when creating them in +maintainer scripts), and allows local administrators to delete the +contents of directories such as ``/var/cache`` with the assurance that +``tmpfiles.d`` can recreate the necessary file structure without +reinstalling packages or re-running maintainer scripts. + +For information on how to specify files and directories that should be +managed by the ``tmpfiles.d`` mechanism, see :manpage:`tmpfiles.d(5)`. + +If the files or directories are only needed by a system service or +otherwise should only be created when that service is running, packages +should define those files and directories in the ``systemd`` unit for the +service (and, for alternative init systems, in the configuration for that +init system) instead of using the ``tmpfiles.d`` mechanism. See +:ref:`s-services-dirs` for more details. + +The ``tmpfiles.d`` mechanism may also be used to create and manage files +and directories under ephemeral file systems such as ``/tmp`` and +``/run``, although these are more likely to be associated with a running +service and in those cases should be defined in the ``systemd`` unit for +the service. + +All packages that ship ``tmpfiles.d`` configuration should declare a +dependency on:: + +default-systemd-tmpfiles | systemd-tmpfiles + +If the package uses ``tmpfiles.d`` features that are not supported by all +implementations of the ``systemd-tmpfiles`` virtual package in the stable +release prior to the release being targeted, instead use:: + +default-systemd-tmpfiles (>= v) | systemd-tmpfiles (>= v) + +where ``v`` is the version of ``systemd`` in which the features were +introduced. + +All packages that ship ``tmpfiles.d`` configuration should arrange for +that configuration to be processed during package installation. This +should be handled by the packaging helper framework; for example, packages +using ``debhelper`` should use ``dh_installtmpfiles``, which will add the +appropriate commands to the package maintainer scripts. + +The init system must ensure that ``tmpfiles.d`` configuration is applied +during boot and that ``tmpfiles.d`` cleanup rules are invoked +periodically. See :manpage:`systemd-tmpfiles(8)` for more information on +how to do this. + .. [#] If you are using GCC, ``-fPIC`` produces code with relocatable position independent code, which is required for most architectures diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst index 724074c..e43340f 100644 --- a/policy/ch-maintainerscripts.rst +++ b/policy/ch-maintainerscripts.rst @@ -50,6 +50,11 @@ absolute pathname. Maintainer scripts should also not reset the appending package-specific directories. These considerations really apply to all shell scripts. +Maintainer scripts should not be used to create empty directories in +``/var`` or ``/etc``, or symlinks or files with trivial content in +``/var``. Instead, use the ``tmpfiles.d`` mechanism to manage those +directories and files. See :ref:`s-tmpfiles.d` for more information. + .. _s-idempotency: Maintainer scripts idempotency diff --git a/policy/ch-opersys.rst b/policy/ch
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Russ Allbery writes: > 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. Here's an updated version with that change plus some other minor fixes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/debian/changelog b/debian/changelog index 4cead28..44a3710 100644 --- a/debian/changelog +++ b/debian/changelog @@ -24,17 +24,6 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium Seconded: Helmut Grohne Seconded: Guillem Jover Closes: #970234 - * Policy: Binary and Description fields may be absent in .changes -Wording: Russ Allbery -Seconded: Sam Hartman -Seconded: Guillem Jover -Closes: #963524 - * Policy: systemd units are required to start and stop system services -Wording: Luca Boccassi -Wording: Russ Allbery -Seconded: Luca Boccassi -Seconded: Sam Hartman -Closes: #1039102 -- Sean Whitton Wed, 14 Jun 2023 16:58:40 +0100 diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index d5c9d68..4bab7df 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory in some cases) +- :ref:`Binary ` (mandatory) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory in some cases) +- :ref:`Description ` (mandatory) - :ref:`Closes ` @@ -812,16 +812,12 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions of the binary packages being uploaded. If no binary -packages are being uploaded, this field will not be present. - -When used inside a ``.changes`` file, the ``Description`` field has a -different format than in source or binary control files. It is a multiline -field with one line per binary package. The first line of the field value -(the part on the same line as ``Description:``) is always empty. Each -subsequent line is indented by one space and contains the name of a binary -package, a space, a hyphen (``-``), a space, and the short description -line from that package. +the descriptions for the packages being uploaded. For this case, the +first line of the field value (the part on the same line as +``Description:``) is always empty. It is a multiline field, with one +line per package. Each line is indented by one space and contains the +name of a binary package, a space, a hyphen (``-``), a space, and the +short description line from that package. .. _s-f-Distribution: @@ -931,8 +927,7 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). If no -binary packages are being uploaded, this field will not be present. +packages being uploaded, separated by whitespace (not commas). .. _s-f-Installed-Size: diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..fa3e5be 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories in ``/var`` or ``/etc``, or +symlinks or files with trivial content in ``/var``, to implement their +functionality. Examples include directories under ``/var/cache`` that are +writable by the package as cache areas, an initially-empty directory in +``/etc`` intended for local overrides added by the local system +administrator, or a file in ``/var`` that should default to a symlink +elsewhere on the system but may be changed later. + +Rather than include these symlinks, files, or directories in the binary +package or create them in package maintainer scripts, packages should use +the ``tmpfiles.d`` mechanism to specify the files and directories that +should be created. This allows associating these files and directories +with specific packages (not currently possible when creating them in +maintainer scripts), and allows local administrators to delete the +contents of directories such as ``/var/cache`` with the assurance that +``tmpfiles.d`` can recreate the necessary file structure without +reinstalling packages or re-running maintainer scripts. + +For information on how to specify fil
Bug#1051371: Post-/usr-merge paths for script interpreters
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/>
Re: Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
I'm going to take this reply out of the bug to just the Policy list, since this really isn't part of the bug discussion and folks trying to understand the bug shouldn't need to read through it. I should have done that with my original message. I'm going to leave the subject line the same so that people who are skipping this thread can keep skipping it. The arguments in the bug stopped after my last message, which I very much appreciate. However, there is a remaining point here that I believe has to be addressed. After this message, I'll go back and address the substance of the bug report in the bug. Luca Boccassi writes: > Secondly, and less importantly, while I appreciate it's not how you > handle policy changes, the way the rest of the distribution works is by > 'building consensus' on mailing lists. Now I don't particularly like it, > but it is what it is. And that means if somebody comes up with the most > egregious nonsense like, to pick a completely fictional example, "hey > folks, usr-merge broke docker, rsync and ansible, we need to revert it", > and it is left unchallenged, then it becomes doxa. So it has to be > challenged. Every time. After half a decade, you don't think _that_ is > exhausting? Sam wrote a very nice response to this already, which I also agree with. I'm going to be considerably more blunt, because I want to make sure this is unambiguous and clear. The following is with my Policy Editor hat on and with Sean's agreement as a statement from the Policy Editors. Not only do you not need to repeatedly refute everything you disagree with in Policy discussions, you (and anyone else, for that matter) *may not* argue this way in Policy discussions. If you continue doing that on a bug you opened, we will close that bug and not consider it further unless someone else can present the problem in a constructive way. If that isn't sufficient to stop this escalation spiral, we will look for more drastic measures. Policy work is a delegated position, and the debian-policy list and BTS is where that work happens. This style of argument is a direct impediment to that work. It fills bug discussions with escalating and repetitive arguments that interfere with understanding the underlying problem and writing good policy guidance. The rest of Debian can and does make its own decisions about what styles of argument it wants to allow, but in this corner of Debian that we are responsible for, we're not going to tolerate it. Nearly all of the people who read these discussions are experts with their own considerable knowledge of Debian. They are quite capable of understanding what areas of Debian are contentious, and are not prone to blindly believing statements people make about them. Participants can, and are encouraged to, calmly refute arguments or statements they disagree with, once, after which they should assume that everyone following the discussion can read and remembers what they said. If specific Policy language that seems to be based on erroneous information is proposed for seconds, then by all means bring the refutation up again at that point. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date
Guillem Jover writes: > How about the attached patch, based on the text in deb-substvars(5)? This looks great, thank you. Seconded. > From 024d94daeb0ab0e7c447868a1b8f9ff953850404 Mon Sep 17 00:00:00 2001 > From: Guillem Jover > Date: Tue, 12 Sep 2023 22:47:27 +0200 > Subject: [PATCH] Update Installed-Size algorithm used by dpkg since 1.18.0 > The previous algorithm relied entirely on du(1) computing the used > size, but depended on the filesystem in use on the build system. > The new algorithm used by dpkg since 1.18.0 (implemented in > commit 9ed7d4d47b73ffe67e1f7d31f899a1dfd43d490b), guarantees a > constant and reproducible size regardless of the build system > filesystem being used. Although it is still an approximation of > the actual size that the package will use on the installed system. > Closes: #793499 > --- > policy/ch-controlfields.rst | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 45776ea..2871658 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -939,8 +939,9 @@ space required to install the named package. Actual > installed size may > vary based on block size, file system properties, or actions taken by > package maintainer scripts. > > -The disk space is given as the integer value of the estimated installed > -size in bytes, divided by 1024 and rounded up. > +The disk space is given as the accumulated size of each regular file and > +symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other > +filesystem object type. > > .. _s-f-Files: -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
Helmut Grohne writes: > 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. > Quite obviously this approach completely breaks cross building. It also > is unclear how it affects reproducible builds since such builds depend > on the performance characteristics of the system performing the build. > This makes it very obvious that the pgo technique has downsides that > warrant disabling it in some situations. > A number of packages have agreed on disabling such optimization when > DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages: > * binutils > * cross-toolchain-base > * gcc-VER > * halide > * pythonVER > I'll also be filing a patch for foot to support this option. > Is this sufficient coverage to document the option already? Yes, I think that's plenty. I would love to have Policy be a bit more proactive about documenting things like this. > Proposed wording: > This tag requests that any optimization performed during the build > should not rely on performance characteristics captured during the > build. Such optimization is usually called profile guided > optimization. Could you specifically mention cross-building (and possibly reproducible builds) as an example of why someone may want to set this option? I think having those sorts of explanations add a lot of value to Policy, since they help explain to the reader how Debian is designed beyond just a mechanical set of instructions. If you have a chance, feel free to send a proposed diff to add this to the DEB_BUILD_OPTIONS section. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > Strictly speaking it is not (as I was more narrowly focusing on) that > the current debian/copyright spec leaves room for *ambiguity*, but > instead that there is a real risk of making mistakes when replacing with > centrally defined ones (e.g. redefining a local "Expat" from locally > meaning "MIT-ish legalese as stated in this project" to falsely mean > "the MIT-ish legalese that SPDX labels MIT"). Right, the existing copyright format defines a few standard labels and says that you should only use those labels when the license text matches, but it doesn't stress that "matches" means absolutely word-for-word identical. I suspect, although I haven't checked, that we've made at least a few mistakes where some license text that's basically equivalent to Expat is labelled as Expat even though the text is not word-for-word identical. Given that currently all labels in debian/copyright are essentially local and the full text is there (except for common-licenses, where apart from BSD the licenses normally are used verbatim), this is not currently really a bug. But we could turn it into a bug quite quickly if we relied on the license short name to look up the text. To take an example that I've been trying to get rid of for over a decade, many of the /usr/share/common-licenses/BSD references currently in the archive are incorrect. There are a few cases where the code is literally copyrighted only by the Regents of the University of California and uses exactly that license text, but this is not the case for a lot of them. It looks like a few people have even tried to say "use common-licenses but change the name in the license" rather than reproducing the license text, which I don't believe meets the terms of the license (although it's of course very unlikely that anyone would sue over it). A quick code search turns up the following examples, all of which I believe are wrong: https://sources.debian.org/src/mrpt/1:2.10.0+ds-3/doc/man-pages/pod/simul-beacons.pod/?hl=35#L35 https://sources.debian.org/src/gridengine/8.1.9+dfsg-11/debian/scripts/init_cluster/?hl=7#L7 https://sources.debian.org/src/rust-hyphenation/0.7.1-1/debian/copyright/?hl=278#L278 https://sources.debian.org/src/nim/1.6.14-1/debian/copyright/?hl=64#L64 https://sources.debian.org/src/yade/2023.02a-2/debian/copyright/?hl=78#L78 An example of one that probably is okay, although ideally we still wouldn't do this because there are other copyrights in the source: https://sources.debian.org/src/lpr/1:2008.05.17.3+nmu1/debian/copyright/?hl=15#L15 This problem potentially would happen a lot with the BSD licenses, since the copyright-format document points to SPDX and SPDX, since it only cares about labeling legally-equivalent documents, allows the license text to vary around things like the name of the person you're not supposed to say endorsed your software while still receiving the same label. We therefore cannot use solely SPDX as a way of determining whether we can substitute the text of the license automatically for people, because there are SPDX labels for a lot of licenses for which we'd need to copy and paste the exact license text because it varies. At least if I understand what our goals would be. (License texts that have portions that vary between packages they apply to are a menace and make everything much harder, and I really wish people would stop using them, but of course the world of software development is not going to listen to me.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > If you mean to say that ambiguous MIT declarations exist in > debian/copyright files written using the machine-readable format, then > please point to an example, as I cannot imagine how that would look. I can see it: people use License: Expat but then include some license that is essentially, but not precisely, the same as Expat. If we then tell people that they can omit the text of the license and we'll fill it in automatically, they'll remove the actual text and we'll fill it in with the wrong thing. This is just a bug in handling the debian/copyright file, though. If we take this approach, we'll need to be very explicit that you can only use whatever triggers the automatic inclusion of the license text if your license text is word-for-word identical. Otherwise, you'll need to cut and paste it into the file as always. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Sam Hartman writes: >>>>>> "Luca" == Luca Boccassi writes: > Luca> Thank you, looks good to me, seconded. > LGTM too, seconded. Thanks! This has now been merged for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#872587: Document the Protected field
Control: retitle -1 Document the Protected field Adam Borowski writes: > On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote: >> Do you have any idea how long we can expect to wait until dpkg supports >> the field? I would suggest that we wait until dpkg has defined >> behaviour for the field, as it will make documenting it much easier. >> It will also allow us to be more confident that there is no serious >> disagreement about the purpose of the field. > Right, let's have dpkg maintainers tell us what they think. >> I couldn't find a bug against dpkg, but if there is one, it should >> probably be set to block this bug. > 872587 < 872589, I filed the Policy one first. Block added. Per the resolution of #872589, this was implemented as the Protected field instead. Retitling the bug accordingly. The documentation from deb-control(5) is: Protected: yes|no This field is usually only needed when the answer is yes. It denotes a package that is required mostly for proper booting of the system or used for custom system-local meta-packages. dpkg(1) or any other installation tool will not allow a Protected package to be removed (at least not without using one of the force options). It's probably also worth noting the parenthetical comment in the documentation of Essential: Essential: yes|no This field is usually only needed when the answer is yes. It denotes a package that is required for the packaging system, for proper operation of the system in general or during boot (although the latter should be converted to Protected field instead). dpkg(1) or any other installation tool will not allow an Essential package to be removed (at least not without using one of the force options). (And while we're there, we don't document the Build-Essential field either.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Guillem Jover writes: > Seconded. Thanks! I think the wording changes subsequent to Sam's second are informative and within the changes the Policy Editor can make without seconds, so I'm proceeding with this and Sam's second and have merged this change for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
be doing. It would enable future competition around better packaging helpers (and I do think debhelper will not be the last word). But I also want to be realistic about whether we're really capable of maintaining that specification. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > On 2023-09-11 11:25:34, Russ Allbery wrote: >> Antoine Beaupré writes: >>> I get the argument against bad binaries not being in PATH but we have >>> some tooling for that, don't we? /usr/libexec, no? >> /usr/libexec isn't a replacement because it's not on any user's PATH. >> /usr/games is intended to be added to a regular user's path but not >> root's, which is a distinct use case. > That's an odd argument to make: /usr/games isn't on any user's PATH > either, is it? It's common to add it, and I'm fairly sure we have documentation that tells you to add it, whereas adding /usr/libexec to your PATH is a bug and something that you should not do. The binaries in /usr/libexec are not intended to be invoked directly, may conflict with other binaries, may do bizarre things when run from the command line, etc. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > I get the argument against bad binaries not being in PATH but we have > some tooling for that, don't we? /usr/libexec, no? /usr/libexec isn't a replacement because it's not on any user's PATH. /usr/games is intended to be added to a regular user's path but not root's, which is a distinct use case. Thanks, Simon and Bill. I had forgotten about that point even though it has come up before (just not in this bug). I agree that's a more compelling argument for keeping /usr/games. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > I wonder if we should just do the same. I'm not sure I see the point of > having all that stuff in a separate directory, personnally, but at least > in this case we shouldn't needlessly diverge from upstream... although > in terms of upstream for bsd-games, things are kind of hazy, at best, > from what I understand. I am inclined to agree; it's just one more thing for people to think about while packaging things, and I don't think it serves much of a useful purpose. However, the bug log has a couple of concrete objections. Axel Beckert objected because games may conflict with other tools installed in /usr/bin. I feel like this is already a bug and merging the two namespaces to force us to deal with that bug may be a feature in disguise, because having two binaries with entirely different purposes on the user's PATH is a recipe for confusion and problems. The two bugs cited were: https://bugs.debian.org/845629 https://bugs.debian.org/752114 which are about a conflict between the game pacman and the package manager pacman. The game pacman now appears to be orphaned but does indeed still ship /usr/games/pacman, and /usr/bin/pacman is provided by pacman-package-manager. There was also one request (from Alexandre Detiste) to retain this separation that, if I understood it correctly, was based on wanting to block access to games for children with accounts on the system. This is similar the old multiuser timeshare use case for separating games back when they competed for resources with other uses of the system and administrators wanted to be able to stop people from running them until after hours. I feel like this use case is exceptionally rare at this point, and I'm not sure it's worth the packaging thought to maintain a separation just for that. Alexandre also requested keeping games data separate so that it could be moved out of the /usr partition because it could be quite large. This is another concern that I think in the subsequent eight years has become a bit less compelling due to the increase in the size of disks (which is only sort of keeping up with full commercial games, but is certainly keeping up with the games packaged in Debian). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Two more things went missing: Simon's suggestion on the versioned > dependencies on the virtual packages, Ah, yes, I'm sorry, I talked myself out of that and then completely forgot the previous discussion so didn't say anything. My concern is that it felt like we were providing a detailed description of an entirely normal dependency management situation (you always have to depend on the version of a package you use that provides the interface you're using unless it's old enough that it doesn't matter), and I wasn't sure what was special about this one that warranted spelling that out other than the need to add the version constraint to both stanzas. So I kept that part but omitted the rest. The phrasing Simon proposed I think would be appropriate if we thought most packages would need a version constraint, but I didn't think the functionality was changing that quickly. Am I wrong about that? It felt awkward to include the version constraints and then tell people to remove them if they're going to be able to remove them 95% of the time, but I don't know if that's the case. 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. > and the link from the tmpfiles section to the service directory section > (given it was moved). It's there (last sentence): +If the files or directories are only needed by a system service or +otherwise should only be created when that service is running, packages +should define those files and directories in the ``systemd`` unit for the +service (and, for alternative init systems, in the configuration for that +init system) instead of using the ``tmpfiles.d`` mechanism. See +:ref:`s-services-dirs` for more details. You don't need to spell out the section title; Sphinx defaults to adding that for you based on the heading that you're linking to. (I think we are excessively explicit in a bunch of places in Policy currently due to a conversion artifact from DebianDoc-XML.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
As usual, the things I notice only after I post text, even though I'd already read it several times. Russ Allbery writes: > +Volatile and temporary files (``tmpfiles.d``) > +- > + > +Some packages require empty directories, files with trivial content (such > +as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement > +their functionality. Luca carefully worded this to avoid talking about files in /etc, and then I lost that distinction. I now have: Some packages require empty directories in ``/var`` or ``/etc``, or symlinks or files with trivial content in ``/var``, to implement their functionality. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Moved as suggested. Also incorporated your suggestion on the versioned > virtual package dependency verbatim. Okay, I felt like doing editing this evening, apparently, so even though only you, Sam, and Simon had a chance to respond, I went ahead and did the editing. I'm guessing we still have some discussion to get through, but attached is a revised diff that I think captures the content of your diff but adds some additional explanation and justification that I was kind of craving. Please let me know if I messed up any of the meaning here. Note that this adds a must (held over from Luca's "required") for init systems. I don't want to introduce that into Policy until the sysvinit maintainers have had a chance to weigh in or someone can confirm that sysvinit already handles running systemd-tmpfiles appropriately when it is installed. I should note that I dropped the admonition in the maintainer scripts section to use upstream's tmpfiles.d files because admonitions of this type (from Lintian and elsewhere) annoy me. The maintainer is in the best possible position to balance the advantages of using upstream configuration that is shared across distributions, bugs in the upstream version that aren't fixed, upstream's ability to maintain those files directly, whether upstream accepts contributions promptly, and whether there are Debian-specific integration concerns that need to be addressed. Less personally and more specific to Policy, making appropriate decisions about when to use upstream files and when to use Debian-specific files is a maintainer experience and expertise issue, not a Policy issue. Policy defines how the packages should work and is agnostic about where the pieces of it come from. If we want to give maintainers advice on how to integrate upstream packages, I think that should go into Developers Reference instead. There was some earlier discussion in this bug about the possibility of using tmpfiles.d to manage things like /run directories that, under sysvinit, are currently managed in a somewhat ad hoc and untrackable way, such as via mkdir in the init script. I still think there's something there, but I don't see a good way to describe it without creating possible problems, so I left it out. > We don't have to handle it with this change/bug and as mentioned I've > already reworded it as suggested, but to clarify my thinking there, the > place I was coming from was the factory reset and first boot angle. When > doing a first boot with only the OS vendor tree under /usr and nothing > else, you want to get to a working system, and if there are complex > files created under /var by maintainer scripts, that's kinda of a > problem. Should Debian decide to adopt the OS vendor tree concept, I certainly understand how what gnubg does would interfere with that. This seemed like the best of a set of bad options at the time. I may adopt Simon's idea of just putting the generated file in /usr, which would also allow me to drop a Debian-specific patch; I didn't do that because putting files in /usr that dpkg doesn't know about felt icky, but Simon is correct that there are a lot of other precedents. > Perhaps those complex binaries should be created by oneshot services > that run at boot with a ConditionPathExists=!/var/some/complex/binary > other than maintainer scripts? That way if /var is blown away, you still > get a working system on next boot. Yes, I could also do something like that. Of course, the point may be moot if upstream never ports GNU Backgammon to anything newer than Gtk+ 2, and the chances of that port currently aren't looking great. > But again, happy to shelve this for now, as it's a more complex topic. Agreed, we don't have to cross this bridge today. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..cc685fe 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,65 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories, files with trivial content (such +as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement +their functionality. Examples include directories under ``/var/cache`` +that are writable by the package as cache areas, an initially-empty +directory in ``/etc`` intended for local overrides added by the local +system administrator, or a file in ``/var`` that should default to a +symlink elsewhere on the system but may be changed later. + +Rather than include these files and directories in the binary package or +create them in package maintainer scripts, pa
Bug#970234: consider dropping "No hard links in source packages"
Guillem Jover writes: > I'm not really sure what the footnote really refers to, TBH, as I'm not > aware of any such check, or what would require a fair amount of > work. Yeah, it seems to be a mystery to everyone. There is an explicit entry in the debian/changelog of Policy from Ian Jackson about it for version 2.1.1, but all it says is: * Hard links are forbidden in source packages (they didn't work anyway, and can't easily be made to work reliably). This is from when Ian was maintaining dpkg, so presumably he thought something was broken at the time, but it seems to have been lost in history. They do obviously work now. > Besides the other potential issues mentioned on the bug, which I agree > we might not care much about, a case that comes to mind would be that > patching hard linked source files can end up being very confusing, and > might not really break the build but can end up not producing what one > might expect. I've quickly prepared the attached tentative and > completely untested patch, to add a warning in that case, which I guess > I might be targeting for dpkg 1.22.1 (once I've added some tests). Thanks, that does seem like a good idea. > But given that hard links in source packages do not seem prevalent at > all, and that the tooling or linters can be improved in that direction I > suppose it might make sense to lift this specific restriction. Thank you for the review! Now applied for the next release of Policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Guillem Jover writes: > Hmm, the "For this case" comes just after the "no binary packages" which > to me reads as being somewhat referring to it, perhaps the "no binary > packages" sentence should be put at the end of the paragraph to avoid > confusion, or the "For this case" moved instead after the "It is a > multiline field" one or something along those lines? I knew I should have listened to my instincts and reworded that paragraph some more to make it explicit that the format of the field in the .changes file is different. (Unfortunate, but oh well, too late now.) Here is an updated patch that restructures this paragraph to try to make this clearer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 21:17:55 -0700 Subject: [PATCH] Binary and Description optional in .changes In .changes files for source-only uploads, the Binary and Description fields are not present. Document this, and be clearer in the description of the Description field for .changes files that only descriptions of binary packages are included. --- policy/ch-controlfields.rst | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 4bab7df..d5c9d68 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory) +- :ref:`Binary ` (mandatory in some cases) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory) +- :ref:`Description ` (mandatory in some cases) - :ref:`Closes ` @@ -812,12 +812,16 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions for the packages being uploaded. For this case, the -first line of the field value (the part on the same line as -``Description:``) is always empty. It is a multiline field, with one -line per package. Each line is indented by one space and contains the -name of a binary package, a space, a hyphen (``-``), a space, and the -short description line from that package. +the descriptions of the binary packages being uploaded. If no binary +packages are being uploaded, this field will not be present. + +When used inside a ``.changes`` file, the ``Description`` field has a +different format than in source or binary control files. It is a multiline +field with one line per binary package. The first line of the field value +(the part on the same line as ``Description:``) is always empty. Each +subsequent line is indented by one space and contains the name of a binary +package, a space, a hyphen (``-``), a space, and the short description +line from that package. .. _s-f-Distribution: @@ -927,7 +931,8 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). +packages being uploaded, separated by whitespace (not commas). If no +binary packages are being uploaded, this field will not be present. .. _s-f-Installed-Size: -- 2.40.1
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > I have so far worked the most on identifying and grouping source data, > putting only little attention (yet - but do dream big...) towards > parsing and processing debian/copyright files e.g. to compare and assess > how well aligned the file is with the content it is supposed to cover. > So if I understand your question correctly and you are not looking for > the output of `licensecheck --list-licenses`, then unfortunately I have > nothing exciting to offer. I think that's mostly correct. I was wondering what would happen if one ran licensecheck debian/copyright, but unfortunately it doesn't look like it does anything useful. I tried it on one of my packages (remctl) that has a bunch of different licenses, and it just said: debian/copyright: MIT License and apparently ignored all of the other licenses present (FSFAP, FSFFULLR, ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and GPL-3.0-or-later with Autoconf-exception-generic). It also doesn't notice that some of the MIT licenses are variations that contain people's names. (I still put all the Autoconf build machinery licenses in my debian/copyright file because of the tooling I use to manage my copyright file, which I also use upstream. I probably should change that, but I need to either switch to licensecheck or rewrite my horrible script.) Also, presumably it doesn't know about copyright-format since it wouldn't be expecting that in source files, so it wouldn't know to include licenses referenced in License stanzas without the license text included. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Johannes Schauer Marin Rodrigues writes: > I very much like this idea. The main reason maintainers want more > licenses in /usr/share/common-licenses/ is so that they do not anymore > have humongous d/copyright files with all license texts copypasted over > and over again. If long texts could be reduced to a reference that get > expanded by a machine it would make debian/copyright look much nicer and > would make it easier to maintain while at the same time shipping the > full license text in the binary package. > Does anybody know why such an approach would be a bad idea? I can think of a few possible problems: * I'm not sure if we generate binary package copyright files at build time right now, and if all of our tooling deals with this. I had thought that we prohibited this, but it looks like it's only a Policy should and there isn't a mention of it in the reject FAQ, so I think I was remembering the rule for debian/control instead. Of course, even if tools don't support this now, they could always be changed. * If ftp-master has to review the copyright files of each binary package separate from the copyright file of the source package (I think this would be an implication of generating the copyright files during build time), and the binary copyright files have fully-expanded licenses, that sounds like kind of a pain for the ftp-master reviewers. Maybe we can deal with this with better tooling, but someone would need to write that. * If we took this to its logical end point and did this with the GPL as well, we would add 20,000 copies of the GPL to the archive and install a *lot* of copies on the system. Admittedly text files are small and disks are large, but this still seems a little excessive. So maybe we still need to do something with common-licenses? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jeremy Stanley writes: > I'm surprised, for example, by the absence of the ISC license given that > not only ISC's software but much of that originating from the OpenBSD > ecosystem uses it. My personal software projects also use the ISC > license. Are you aggregating the "License:" field in copyright files > too, or is it really simply a hard-coded list of matching patterns? It's only a hard-coded list of matching patterns, and it doesn't match any of the short licenses because historically I wasn't considering them (with the exception of common-licenses references to the BSD license, which I kind of would like to make an RC bug and clean up so that we could remove the BSD license from common-licenses on the grounds that it's specific to only the University of California and confuses people). If we go with any sort of threshold, the script will need serious improvements. That was something else I wanted to ask: I've invested all of a couple of hours in this script, and would be happy to throw it away in favor of something that tries to do a more proper job of classifying the licenses referenced in debian/copyright. Has someone already done this (Jonas, perhaps)? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Guillem Jover writes: > Seems I missed another file: > * .changes: > policy → «upload control file» / «Debian changes file» > dpkg → «upload control file» / «.changes control file» / > «Debian .changes file» / «Debian changes file» [...] > For changes I think something like the following might be a more clear > option (and has the minor bonus of aligning perfectly on the first > words! :), with it mentioning explicitly this is about changes being > uploaded, and that it is a control file (but I'm not sure I'm entirely > convinced about it): > * .changes: «Debian upload changes control files» [...] > I've also found instances of «record» and «section» referring to fields > or stanzas. [...] > I also recalled another term that has always seemed very confusing in > context: «control information files» or «control information area». For > example in a sentence such as “the control file is a control information > file in the control information area in a .deb archive”. :) This also > seems confusing when some of the files in the .deb control member are > not really “control files” with a deb822(5) format. > My thinking has been going into calling these as the «metadata files», > and being located in either the «metadata part of the .deb archive» or > explicitly the «control member of the .deb archive», in contrast to the > filesystem part. In dpkg I'd be eventually switching to meta/metadata > and fsys/filesystem, from control or info and data. I've added a patch > with the proposed change, but again nothing set in stone, and I'm again > open to discussing pros/cons of this. > Attached the proposals for discussion/review, and I might again have > perhaps missed instances or similar. All of these changes seem straightforward and uncontroversial to me, and there are huge advantages to using consistent terminology between Policy and dpkg. I have applied all of them for the next Policy release. Thank you! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#830913: debian-policy: Allow amd64 systems without /lib64
Russ Allbery writes: > It's now been about a year and it looks like this message didn't get a > reply, so I'm going to go ahead and close this bug because I don't think > we have enough information to act on it. If there are more details > about my questions above, feel free to open it. For the sake of the record on this now-closed bug, I got a reply from Javier Serrano Polo asking if I had received a message related to this bug last year. I don't remember receiving one, and it's not present in the BTS. I attempted to reply to that message saying so, but the jasp.net mail server rejected my mail message with the following bounce message: : host www.jasp.net[84.126.37.22] said: 550-The message does not meet the trust level of one recipient at least 550-See http://www.jasp.net/smtp/trust.xhtml 550 Administrative prohibition (in reply to end of DATA command) I don't think this changes anything about the original analysis, so I'm leaving this bug closed, but I wanted to clarify my last message; apparently there is some communication blockage here. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas
Simon McVittie writes:
> Here are some updated patches for Policy, incorporating this requirement.
> I have not attempted to incorporate the corner case involving
> build-profiles. I think if we were going to do that, it would require
> documenting build-profiles first (#757760), and maybe even then it's too
> much of a corner-case to be documenting unless/until it actually
> happens.
I also second these changes. In the name of expediency, and since I
believe all the proposed wording changes were informative, I applied these
patches for the next release and made the wording changes suggested by
Holger and Sean. Attached are the changes as committed.
Subsequent to this work, we added the non-free-firmware archive area.
Simon's patch therefore doesn't add a statement to that section about
whether source packages in non-free-firmware are allowed to produce
binaries in non-free, or if source packages in non-free are allowed to
produce binaries in non-free-firmware, and I don't know what the answer to
that is.
Would the following wording be correct?
If a source package is in the *non-free-firmware* archive area, then
each of the binary packages that it produces must also be in the
*non-free-firmware* archive area.
Please let me know, and I will propose some follow-up wording for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/debian/changelog b/debian/changelog
index 66d6fa0..a5e3e3e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,11 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium
Seconded: Russ Allbery
Seconded: Holger Levsen
Closes: #1035733
+ * Policy: Source packages in main may build binary packages in contrib
+Wording: Simon McVittie
+Seconded: Holger Levsen
+ Seconded: Russ Allbery
+Closes: #994008
-- Sean Whitton Wed, 14 Jun 2023 16:58:40 +0100
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index c7cd340..eb8978a 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -136,6 +136,27 @@ In addition, the packages in *main*
- must meet all policy requirements presented in this manual.
+If a source package is in the *main* archive area, then at least one of
+its binary packages must be in the *main* archive area, and each of the
+remaining packages must be in either the *main* or *contrib* archive
+area. Each binary package's archive area is indicated by its ``Section``
+field: see :ref:`s-subsections`.
+
+Source packages in *main* with a mixture of *main* and *contrib* binary
+packages are more complex for archive tooling to handle, and therefore
+should be limited to situations where it would be inconvenient to split
+the source package. If it is straightforward to split the source package
+into a *main* part and a *contrib* part that are built separately, then
+those parts should be represented as separate source packages.
+
+When a *main* source package has a mixture of *main* and *contrib* binary
+packages, the source package and the *main* binary packages must follow
+the requirements for *main* packages, but the *contrib* binary packages
+may follow the weaker requirements for *contrib* packages. In particular,
+source packages in *main* must not have build dependencies outside *main*,
+but the *contrib* binary packages may have runtime dependencies outside
+*main*.
+
.. [2]
See `What Does Free Mean? <https://www.debian.org/intro/free>`_ for
more about what we mean by free software.
@@ -192,6 +213,10 @@ Examples of packages which would be included in *contrib* are:
- wrapper packages or other sorts of free accessories for non-free
programs.
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
.. _s-non-free:
The non-free archive area
@@ -214,6 +239,10 @@ In addition, the packages in *non-free*
- must meet all policy requirements presented in this manual that it is
possible for them to meet. [4]_
+If a source package is in the *non-free* archive area, then each of the
+binary packages that it produces must also be in the *non-free* archive
+area.
+
.. [4]
It is possible that there are policy requirements which the package
is unable to meet, for example, if the source is unavailable. These
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 54a473b..6009819 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -44,6 +44,13 @@ Version 4.7.0
Unreleased.
+2.2.1
+Document that source packages in the *main* archive area may build
+binary packages in the *contrib* archive area, although this is
+discouraged unless the source package is inconvenient to split. This
+does not relax the requirement that source packages in *main* must not
+have build dependencies outside of *main*.
+
2.2.
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
Russ Allbery writes: > This patch from a while back is still waiting for one more second before > it can be merged for the next Policy release. It previously got one > second from Wouter. I revised the patch to mention the experimental > suite as well as the backports suites. Argh, wrong patch, sorry. Here is the one that was actually updated to include experimental. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 7ee49f6c892d6057b9a0d2f9eb84ff0f35d1d436 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 19:11:54 -0700 Subject: [PATCH] Improve alternative build dependency discussion Alternatives in build dependencies are normally (except for backports) handled specially by autobuilders to try to maintain consistent builds. This was documented in Policy, but in a footnote that people often didn't see. Move this text into the main body of the discussion of build dependencies and reword it for additional clarity. Add a pointer to this discussion where alternative dependencies are introduced. --- policy/ch-relationships.rst | 61 +++-- 1 file changed, 45 insertions(+), 16 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index 5074428..ffafbf1 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols ``|``. In such a case, that part of the dependency can be satisfied by any one of the -alternative packages. [#]_ +alternative packages. (Alternative dependencies in ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted +specially by Debian autobuilders. See :ref:`Relationships between source +and binary packages ` for more details.) All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual @@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in ``Build-Conflicts-Arch`` fields must be satisfied when these targets are invoked. +Alternative dependencies are allowed in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's +autobuilders normally discard the dependencies after the first. This is +done to give alternative dependencies a consistent interpretation that +reduces the risk of inconsistencies between repeated builds. If, for +example, the first-listed dependency would normally be available but is +temporarily not installable, the autobuilder fails rather than install a +subsequent dependency that may significantly change the behavior of the +package. + +More specifically, Debian autobuilders perform the following +transformation on alternative dependencies in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields: + +#. Discard any alternatives that are restricted to architectures that do + not match the host architecture. +#. Discard any alternatives specifying different package names than the + now-first alternative. (Alternatives specifying the same package name + are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) + +For example, an autobuilder for the ``amd64`` architecture would treat the +following dependency:: + +foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar + +as if it were:: + +foo (<= 4) | foo (>= 4.2) + +The normal effect is to use only the first alternative that is valid on +the relevant architecture and fail if that alternative is not installable. + +While this rule for build dependencies may limit the usefulness of +alternatives, they can still be used to provide flexibility when building +the package outside of Debian's autobuilders. + +The autobuilders for the Debian backports and experimental suites do not +perform this transformation and instead use the same dependency resolution +rules as normal package installations to choose which alternative +dependency to install. + .. _s-built-using: Additional source packages used to build the binary - ``Built-Using`` @@ -666,21 +710,6 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. -.. [#] - While ``Build-Depends``, ``Build-Depends-Indep`` and - ``Build-Depends-Arch`` permit the use of alternative dependencies, - those are only used for the backports suite on the Debian autobuilders. - On the other suites, after reducing any architecture-specific restrictions - for the build architecture in question, all but the first alternative are - discarded except if the alternative is the same package name as the fi
Bug#970234: consider dropping "No hard links in source packages"
This patch is still waiting for one more second. It was previously seconded by Helmut. Russ Allbery writes: > Here is a patch dropping the restriction on hard links in source > packages that I think is ready for seconds. I'm copying Guillem for his > review, in case there's some dpkg concern. > From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Thu, 22 Sep 2022 19:15:52 -0700 > Subject: [PATCH] Allow hard links in source packages > It's not clear why this restriction was in place, and Debian > included a package containing hard links without anyone noticing > in the last release. > --- > policy/ch-source.rst | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-) > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index c7415fc..a7df539 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably > possible. [#]_ > Restrictions on objects in source packages > -- > > -The source package must not contain any hard links, [#]_ device special > -files, sockets or setuid or setgid files.. [#]_ > +The source package must not contain device special files, sockets, or > +setuid or setgid files. [#]_ > > .. _s-debianrules: > > @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for > any ``foo``. > would be nice if the modification time of the upstream source would > be preserved. > > -.. [#] > - This is not currently detected when building source packages, but > - only when extracting them. > - > - Hard links may be permitted at some point in the future, but would > - require a fair amount of work. > - > .. [#] > Setgid directories are allowed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
This patch from a while back is still waiting for one more second before it can be merged for the next Policy release. It previously got one second from Wouter. I revised the patch to mention the experimental suite as well as the backports suites. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 6a4e1b261f5f5765fa164e4bfd063f67d40a9a47 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 19:11:54 -0700 Subject: [PATCH] Improve alternative build dependency discussion Alternatives in build dependencies are normally (except for backports) handled specially by autobuilders to try to maintain consistent builds. This was documented in Policy, but in a footnote that people often didn't see. Move this text into the main body of the discussion of build dependencies and reword it for additional clarity. Add a pointer to this discussion where alternative dependencies are introduced. --- policy/ch-relationships.rst | 61 +++-- 1 file changed, 45 insertions(+), 16 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index 5074428..e8978af 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols ``|``. In such a case, that part of the dependency can be satisfied by any one of the -alternative packages. [#]_ +alternative packages. (Alternative dependencies in ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted +specially by Debian autobuilders. See :ref:`Relationships between source +and binary packages ` for more details.) All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual @@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in ``Build-Conflicts-Arch`` fields must be satisfied when these targets are invoked. +Alternative dependencies are allowed in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's +autobuilders normally discard the dependencies after the first. This is +done to give alternative dependencies a consistent interpretation that +reduces the risk of inconsistencies between repeated builds. If, for +example, the first-listed dependency would normally be available but is +temporarily not installable, the autobuilder fails rather than install a +subsequent dependency that may significantly change the behavior of the +package. + +More specifically, Debian autobuilders perform the following +transformation on alternative dependencies in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields: + +#. Discard any alternatives that are restricted to architectures that do + not match the host architecture. +#. Discard any alternatives specifying different package names than the + now-first alternative. (Alternatives specifying the same package name + are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) + +For example, an autobuilder for the ``amd64`` architecture would treat the +following dependency:: + +foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar + +as if it were:: + +foo (<= 4) | foo (>= 4.2) + +The normal effect is to use only the first alternative that is valid on +the relevant architecture and fail if that alternative is not installable. + +While this rule for build dependencies may limit the usefulness of +alternatives, they can still be used to provide flexibility when building +the package outside of Debian's autobuilders. + +The autobuilders for the Debian backports suite do not perform this +transformation and instead use the same dependency resolution rules as +normal package installations to choose which alternative dependency to +install. + .. _s-built-using: Additional source packages used to build the binary - ``Built-Using`` @@ -666,21 +710,6 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. -.. [#] - While ``Build-Depends``, ``Build-Depends-Indep`` and - ``Build-Depends-Arch`` permit the use of alternative dependencies, - those are only used for the backports suite on the Debian autobuilders. - On the other suites, after reducing any architecture-specific restrictions - for the build architecture in question, all but the first alternative are - discarded except if the alternative is the same package name as the first. - The latter exception is useful to specify version ranges like - ``foo (rel x) | foo (rel y)``. This is to reduce the risk of inconsistencies - betwee
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Here is an updated proposed change for this bug, incorporating Guillem's suggestions. It is ready for seconds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 66175d3775f238a5ce3a2254388ad974e81d462f Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 21:17:55 -0700 Subject: [PATCH] Binary and Description optional in .changes In .changes files for source-only uploads, the Binary and Description fields are not present. Document this, and be clearer in the description of the Description field for .changes files that only descriptions of binary packages are included. --- policy/ch-controlfields.rst | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 4bab7df..904fa52 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory) +- :ref:`Binary ` (mandatory in some cases) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory) +- :ref:`Description ` (mandatory in some cases) - :ref:`Closes ` @@ -812,10 +812,11 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions for the packages being uploaded. For this case, the -first line of the field value (the part on the same line as -``Description:``) is always empty. It is a multiline field, with one -line per package. Each line is indented by one space and contains the +the descriptions of the binary packages being uploaded. If no binary +packages are being uploaded, this field will not be present. For this +case, the first line of the field value (the part on the same line as +``Description:``) is always empty. It is a multiline field, with one line +per binary package. Each line is indented by one space and contains the name of a binary package, a space, a hyphen (``-``), a space, and the short description line from that package. @@ -927,7 +928,8 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). +packages being uploaded, separated by whitespace (not commas). If no +binary packages are being uploaded, this field will not be present. .. _s-f-Installed-Size: -- 2.40.1
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Russ Allbery writes: > In order to structure the discussion and prod people into thinking about > the implications, I will make the following straw man proposal. This is > what I would do if the decision was entirely up to me: > Licenses will be included in common-licenses if they meet all of the > following criteria: > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. In the thread so far, there's been a bit of early convergence around my threshold of 100 packages above. I want to make sure people realize that this is a very conservative threshold that would mean saying no to most new license inclusion requests. My guess is that with the threshold set at 100, we will probably add around eight new licenses with the 25 line threshold (AGPL-2, Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and OFL-1.1, and I'm not sure about some of those because the CC licenses have variants that would each have to reach the threshold independently; my current ad hoc script does not distinguish between the variants), and maybe 10 to 12 total without that threshold (adding Expat, zlib, some of the BSD licenses). This would essentially be continuing current practice except with more transparent and consistent criteria. It would mean not including a lot of long legal license texts that people have complained about having to duplicate, such as the CDDL, CeCILL licenses, probably the EPL, the Unicode license, etc. If that's what people want, that's what we'll do; as I said, that's what I would do if the choice were left entirely up to me. But I want to make sure I give the folks who want a much more relaxed standard a chance to speak up. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > Quoting Hideki Yamane (2023-09-10 11:00:07) >> Hmm, how about providing license-common package and that depends on >> "license-common-list", and ISO image provides both, then? It would be >> no regressions. I do wonder why we've never done this. Does anyone know? common-licenses is in an essential package so it doesn't require a dependency and is always present, and we've leaned on that in the past in justifying not including those licenses in the binary packages themselves, but I'm not sure why a package dependency wouldn't be legally equivalent. We allow symlinking the /usr/share/doc directory in some cases where there is a dependency, so we don't strictly require every binary package have a copyright file. >> I expect license-common-list data as below >> >> license-short-name: URL >> GPL-2: file:///usr/share/common-licenses/GPL-2 >> Boost-1.0: https://spdx.org/licenses/BSL-1.0.html > Ah, so what you propose is to use file URIs. > I guess Russ' response above was a concern over using http(s) URIs > towards a non-local resource. Yes, I think the https URL is an essential part of the first proposal, since it avoids needing to ship a copy of all of the licenses. But I'm dubious that would pass legal muster. The alternative proposal as I understand it would be to haave a license-common package that includes full copies of all the licenses with some more relaxed threshold requirement and have packages that use one of those licenses depend on that package. (This would obviously require a maintainer be found for the license-common package.) > License: Apache-2.0 > Reference: /usr/share/common-licenses/Apache-2.0 This is separate from this particular bug, but I would love to see the pointer to common-licenses turned into a formal field of this type in the copyright format, rather than being an ad hoc comment. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field
Adam Borowski writes: > Agreed, but it might be good to say "it would be good to have this", and > send a bug/mail to the relevant teams, asking if there are objections > before anyone spends work to implement this. > I for one have currently no less than three related ideas: > * this > * richer arch aliases (better than current dpkg aliases; could be >implemented like shell foo-$@-bar word multiplication, thus linux-64bit >would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind >of shot before though > * replacing explicit arch names in source packages by facets (like: >x86, little-endian, sse2, time64, ...) that are expanded at build time; >procrastiplanning to propose this > It's good to discuss such things -- if someone offers to implement such a > change. Yes, I agree. >> going to have to close this bug against Policy as unactionable since I >> don't know of any efforts towards implementing this support, and Policy >> would only be able to change once the support is available. > Could we oh so please have this as a policy policy in other cases, too? Yes, historically I've been reluctant to close Policy bugs that indicate real problems even if no apparent forward progress is being made on that bug, but I'm starting to think this is too conservative and keeping really old stalled bugs open is often not useful. However, there are a lot of bugs and I don't touch them very frequently, since I'm trying to focus on closing bugs that do have forward progress. If you or anyone else has a list of bugs that you think fall into that category (no known efforts towards an implementation, Policy can't change until that implementation happens), please do send a list. (Feel free to send that privately if you think it might be controversial.) I'm happy to take a look. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hideki Yamane writes: > Russ Allbery wrote: >> Licenses will be included in common-licenses if they meet all of the >> following criteria: > How about just pointing SPDX licenses URL for whole license text and > lists DFSG-free licenses from that? (but yes, we should adjust short > name of licenses for DEP-5 and SPDX for it). Can we do this legally? If we can, it certainly has substantial merits, but I'm not sure that this satisfies the requirement in a lot of licenses to distribute a copy of the license along with the work. Some licenses may allow that to be provided as a URL, but I don't think they all do (which makes sense since people may receive Debian on physical media and not have Internet access). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
by it. * The license applies to at least 100 source packages in Debian. * The license text is longer than 25 lines. I will attempt to guide and summarize discussion on this topic. No decision will be made immediately; I will summarize what I've heard first and be transparent about what direction I think the discussion is converging towards (if any). Finally, as promised, here is the count of source packages in unstable that use the set of licenses that I taught my script to look for. This is likely not accurate; the script uses a bunch of heuristics and guesswork. AGPL 3 277 Apache 2.0 5274 Artistic 4187 Artistic 2.0337 BSD (common-licenses)42 CC-BY 1.0 3 CC-BY 2.015 CC-BY 2.513 CC-BY 3.0 240 CC-BY 4.0 159 CC-BY-SA 1.0 8 CC-BY-SA 2.0 48 CC-BY-SA 2.5 16 CC-BY-SA 3.0425 CC-BY-SA 4.0237 CC0-1.01069 CDDL 67 CeCILL 30 CeCILL-B 13 CeCILL-C 9 GFDL (any) 569 GFDL (symlink) 55 GFDL 1.2289 GFDL 1.3231 GPL (any) 20006 GPL (symlink) 1331 GPL 1 4033 GPL 2 10466 GPL 3 6783 LGPL (any) 5019 LGPL (symlink) 265 LGPL 2 3850 LGPL 2.1 2926 LGPL 3 1526 LaTeX PPL46 LaTeX PPL (any) 40 LaTeX PPL 1.3c 32 MPL 1.1 165 MPL 2.0 361 SIL OFL 1.0 11 SIL OFL 1.1 258 -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Sure, updated as suggested. I have a bunch of minor wording fixes that I'd want to make at this before merging, but that should be straightforward to do. Before I invest the time in that, I want to check the opinions of everyone else following along and see if the semantics of Luca's change have general approval. Could folks take a look at this patch and see if the basic gist of it is something that they would second (or, for that matter, is something they would object to)? I think I would second it (with wording adjustments), with one caveat mentioned below. The whole thing is at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#295 Luca, am I right that service directories are specific to, well, services? If so, what would you think of moving them to Policy 9.3 alongside the other discussion of systemd units? They feel out of place here, since packages that do not use services cannot use this functionality, and there's already a statement in the tmpfiles.d section pointing to them as more appropriate for services. > +Packages might need additional files or directories to implement their > +functionality. Directories that are located under ``/var/`` or > +``/etc/``, and files that are located under ``/var/``, should not be > +created manually via maintainer scripts, but instead be declaratively > +defined via the `tmpfiles.d > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_ > +interface. Files and directories under ephemeral filesystems such as > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets. I understand the empty directory part, but I don't believe "files that are located under /var" is correct unless you specifically mean *empty* files (and even then, I'm not clear on precisely when this would be needed). For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package maintainer script, and I can see no possible way that action could (or should) be handled by the tmpfiles.d mechanism. What am I missing? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Russ Allbery writes: > -If a service unit is not present, ``systemd`` uses dependency information > -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide > -which scripts to run and in which order. The ``sysv-rc`` runlevel system > -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which > -scripts to run and in which order at boot time and when the init state (or > -"runlevel") is changed. See the ``README.runlevels`` file shipped with > -``sysv-rc`` for implementation details. Other alternatives might exist. > +``systemd`` uses dependency and ordering information contained within the > ++enabled unit files to decide which services to run and in which order. > +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in > +``/etc/rcn.d`` to decide which scripts to run and in which order at boot > +time and when the init state (or "runlevel") is changed. See the > +``README.runlevels`` file shipped with ``sysv-rc`` for implementation > +details. Other alternatives might exist. And of course I have to post the diff to see the bugs. The part that says "uses the same symlinks" should now say "uses symlinks". -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Luca Boccassi writes: > systemd upstream will drop support for the transitional sysv generator > in the near future. The transition is long finished, it's been at least > a decade, and it's time for the tail of packages still shipping only > init scripts but not units to be updated. > Tentatively this should happen within Trixie's development cycle. Of > course it's free software and generators are not that difficult to > maintain, so if someone wanted to lift the sysv generator out of the > systemd repository and adapt it to be a standalone binary there's > nothing stopping them. But I wouldn't want the systemd package to depend > on such a backward compat tool, so packages needing this hyptothetical > package should depend explicitly on it. This is just mentioned for > completeness, it's been at least a decade and writing a unit file is > beyond trivial so there shouldn't be any issue adding the few remaining > ones. The mass bug filing happened, and although there were some objections on debian-devel, I don't think any of them were blocking. Specifically, I did not see anyone present a concrete plan for how to keep the systemd unit generator or some equivalent alive, and given that systemd upstream is dropping support for this feature, I believe that's the only way for this change to not be effective mandatory. Therefore, I think the time is ripe to proceed with this Policy change. I took a detailed look at this part of Policy today, and the whole system service section needs serious work. I believe the instructions it currently provides for constructing package maintainer scripts won't actually work with a current Debian system, and most Debian packages are technically violating the current Policy because it hasn't been updated for how systemd units work today. I started on overhauling that section, but it became clear that this is going to be a larger project with some potentially controversial decisions, so I'm going to open a new bug about that so that we don't block this change on that work. I made the following changes to your last diff: * Move the "should" about integrating with service management to the parent section. * Explicitly say that systemd is the default init system and service manager (it feels like we should say this somewhere, and I don't think we already do). * Add an explicit exception for packages intended only to support alternate init systems. (As an obvious example, sysvinit isn't going to ship a systemd unit, nor should it.) * Delete the paragraph suggesting that packages without systemd units should write an init script, since this will no longer accomplish the goal of getting that system service to work with systemd and therefore no longer seems to serve a purpose. Here is what I came up with. I think it is ready for seconds or objections. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 9 Sep 2023 18:39:16 -0700 Subject: [PATCH] systemd unit files are now a must systemd is dropping support for the generator that allows it to automatically create units for init scripts. As a result, all packages that want to integrate with systemd service management must start shipping systemd units. State that arranging for services to be automatically started or stopped is a should, but if the package wishes to do that, a systemd service unit is a must unless the package is only intended for use with alternate init systems. Avoid saying that systemd uses /etc/rcn.d links to determine service ordering. --- policy/ch-opersys.rst | 35 --- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 207b3c0..bee16f2 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -323,20 +323,25 @@ which try to write to a home directory will fail to build. Starting system services +Debian packages that provide system services should arrange for those +services to be automatically started and stopped by the init system or +service manager. This section describes how that is done. + .. _s-services-intro: Introduction -Packages that include system services should include ``systemd`` service -units to start or stop those services. See :manpage:`systemd.service(5)` -for details on the syntax of a service unit file. In the common case that -a package includes a single system service, the service unit should have -the same name as the package plus the ``.service`` extension. +The default init system and service manager in Debian is ``systemd``. +Packages that wish to automatically start and stop system services must +include ``systemd`` service units to do so, unless the service is only +intended for use on systems runn
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Package: debian-policy Version: 4.6.2.0 Severity: important X-Debbugs-Cc: r...@debian.org As part of reviewing #1039102, I took a detailed look at Policy 9.3 on system services and realized that it is largely obsolete and is not followed by most Debian packages that provide system services. Specifically: * There is no real documentation of systemd units except in the introduction, and most of the section describes init scripts as if they were the only way to start a service. * All packages are told they must use update-rc.d, but systemd units no longer use update-rc.d. They instead use deb-systemd-helper in ways that are not documented in Policy and I believe are maintained primarily in debhelper. * All packages are told they should use invoke-rc.d, but systemd units no longer use invoke-rc.d. They instead use deb-systemd-invoke, which also supports the policy-rc.d interface. * The policy-rc.d interface is undocumented. This part of Policy is also a bit of a mess of deleted sections due to a desire to avoid section renumbering. I started a rewrite of this section, but quickly ran into the question of how to document the correct invocations of deb-systemd-helper and deb-systemd-invoke. After thinking about this for a while, the conclusion I reached was that documenting this in Policy is both extra make-work that we do not have the resources to keep up with, and serves no real purpose for nearly every reader of Debian. debhelper is already maintaining the correct code to set up systemd services in close cooperation with the systemd and init-system-helpers maintainers, that code contains temporary workarounds and other fixes that Policy is not going to keep up with, and it's hard to justify duplicating that work in a Policy statement. I therefore would like to propose a first: I think Policy should simply say that any package that provides a system service should use debhelper and rely on dh_installsystemd to put the appropriate commands in its maintainer scripts. (We can then discuss whether we should do the same for init scripts and dh_installinit, although its stanzas are simpler.) Previously we have tried to avoid doing this, and have maintained the principle that debhelper is simply an *implementation* of Policy, and it still falls to Policy to describe what debhelper should do. However, I think it is now abundantly obvious that debhelper has considerably more development resources available to it than Policy has writers, debhelper developers are quite rightfully not waiting for things to be added to Policy before they can be implemented, and essentially every Debian package that does anything non-trivial uses debhelper now. I also don't see any truly useful purpose served by dumping a wad of shell code into Policy that essentially no one will use because it's what debhelper would add for them. I have some other questions about the rewrite of these sections (such as how hard we should try to retain section numbering), but I think we should resolve this question first, since it has dramatic effects on what text we should write. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-7 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#1050322: Partial versus complete replacement of a package by another
julien.pu...@gmail.com writes: > Oh. I think I had two problems: > (1) thinking "Replaces" meant "replaces" ; > (2) thinking d/control controlled packages. > Let me try to see if I'm getting at something: > (*) Replaces doesn't really mean "can be used in place of" > -- that would be expressed with Breaks+Provides. > (*) Replaces shouldn't come without Breaks, but doesn't imply it > so we have to put in both (why?). Yes, this is a good question. I recently was confused about this myself despite having worked on Debian and maintained Policy and, at times, Lintian for years, which implies that we don't do a very good job of documenting the ins and outs of this. https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best explanation of this that I've seen. The short summary is that the one case where Breaks is not required is if the package with Replaces also depends on a new version of the package that it is replacing. This prevents the scenario described in the footnote. The other thing that's worth noting is that sometimes you want Breaks and sometimes you want Conflicts, and both Breaks and Conflicts are useful without Replaces for other reasons, so none of them can really imply any of the others. I also saw your other bug (#1050221) about promoting that footnote to the main text. That's a partial fix, but I think we should include some portion of Helmut's explanation directly in Policy as well. (We sort of say this, but we're not nearly as explicit about it as we could be, and we don't use normative language.) > (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and > the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2 > and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure > them or does it refuse with a clear error message? It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2 and foo 1.2-2 is currently configured. foo 1.2-2 has to be unconfigured first before the installation of foo-data 1.2-3 can procede. (This is documented in Policy 7.3 where Breaks is discussed.) What normally happens is that users use apt rather than dpkg directly. I believe apt will force an upgrade of foo because it sees that it is broken by foo-data and will not allow installation of foo-data without either upgrading or removing foo. (dpkg does not do this because dpkg in general operates on only the packages it's told to operate on and doesn't expand the scope of one invocation to change other packages.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions
Control: tags -1 pending Max-Julian Pogner writes: > consulting the debian policy manual whether it contains suggestions how > to best implement diversions (see `man dpkg-divert`), i noticed syntax > errors in the provided shell script example snippets. > a patch fixing these typos is attached. Thanks, applied for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1024367: In 4.9.1, the example uses not recommended install -s
Enrico Zini writes: > Hello, and thank you for maintaining the Policy! > Policy paragraph 4.9.1 has an example debian/rules which contains these > lines: >INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 >ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) >INSTALL_PROGRAM += -s >endif > However, paragraph 10.1 recommends against it: >It is not recommended to strip binaries by passing the "-s" flag to >"install", because this fails to remove .comment and .note sections, >and also prevents the automatic creation of dbgsym binary packages by >tools like "dh_strip". > I would personally prefer if the example built on debhelper. If the > intention is to show what are the expectations at a lower level then > I wish the example had a comment saying "This snippet serves to explain > what are the expectations as a lower level. You usually want to use > debhelper instead" I looked at this snippet and I think it has worse problems than the use of install -s. For example, it predates the existence of dpkg-buildflags, which would also handle noopt. I'm also dubious that it serves any useful purpose given that nearly every package should just use debhelper. The typical current Debian packager seems more likely to be confused by this fragment than aided by it. I'm therefore going to propose fixing this bug with the following patch, which is more aggressive than you propose. I think this is informative rather than normative and therefore technically doesn't require seconds, but I'll give this some time for other people to take a look and talk me out of deleting this section if they wish. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 9 Sep 2023 15:10:21 -0700 Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example The correct way to implement most DEB_BUILD_OPTIONS these days is to just use debhelper. The detailed Makefile fragment was probably more confusing than helpful, given that it predates dpkg-buildflags, uses install -s (which Policy elsewhere recommends against), and manually does other work debhelper would automate. Replace it with a note that packaging helper frameworks do much of this work. --- policy/ch-source.rst | 35 +++ 1 file changed, 3 insertions(+), 32 deletions(-) diff --git a/policy/ch-source.rst b/policy/ch-source.rst index 4307e89..b6f2c86 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -588,38 +588,9 @@ The meaning of the following tags has been standardized: Unknown flags must be ignored by ``debian/rules``. -The following makefile snippet is an example of how one may implement -the build options; you will probably have to massage this example in -order to make it work for your package. - -.. code-block:: Makefile - -CFLAGS = -Wall -g -INSTALL = install -INSTALL_FILE= $(INSTALL) -p-o root -g root -m 644 -INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 -INSTALL_SCRIPT = $(INSTALL) -p-o root -g root -m 755 -INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 - -ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) -CFLAGS += -O0 -else -CFLAGS += -O2 -endif -ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) -INSTALL_PROGRAM += -s -endif -ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -MAKEFLAGS += -j$(NUMJOBS) -endif - -build: -# ... -ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) -# Code to run the package test suite. -endif - +Packaging helper frameworks such as debhelper will automatically support +many of these options without any further work required by the package +maintainer. .. _s-debianrules-gainrootapi: -- 2.40.1
Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field
Samuel Thibault writes: > I didn't find a previous discussion on this: it would be useful to > support negated architecture specifications in the debian/control > Architecture field, so that we can e.g. write: > Architecture: !s390 !s390x > (for xorg stuff) > Architecture: !hppa !hurd-any !kfreebsd-any > (for java stuff) > and even things like > Architecture: linux-any kfreebsd-any !hppa !m68k-any > which would be understood as [ (linux-any or kfreebsd-any) and not hppa > and not m68k-any ]. I.e. if no positive specification is set, an "any" > positive specification is assumed. > That would help to remove quite a few entries of > https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific > and avoid packages with some java bits to have to hardcode the list of > ports on which java jni bindings packages should be built. > I guess support would be needed in dpkg, lintian, etc. Hi Samuel, I agree that this would be useful. This has come up frequently over the years, and back when I was maintaining architecture-specific packages, the lack of this feature was often annoying. But (as may be obvious from the long delay in even getting a response), Policy can't drive the implementation of this change and therefore probably isn't a good place to start with the request. I think it would need to start with dpkg and ftp-master (for DAK). I'm therefore probably going to have to close this bug against Policy as unactionable since I don't know of any efforts towards implementing this support, and Policy would only be able to change once the support is available. If I misunderstood the current state, please do let me know. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area
Gunnar Wolf writes: > It has been four months since the General Resolution 2022/vote_003 was > voted¹, but it has not yet been completely adopted. The archive area was > created and at least a package was uploaded to it in October, but it has > not seen further movement. Two days ago, a call to action for moving > packages was sent by Cyril Brulebois², and I just sent a mail checking > for other places where it should be included³. > ¹ https://www.debian.org/vote/2022/vote_003 > ² https://lists.debian.org/debian-boot/2023/01/msg00150.html > ³ https://lists.debian.org/debian-project/2023/01/msg00018.html > To my surprise, the non-free-firmware archive area has not yet been > discussed for inclusion in the Policy. > I am (now!) aware there is a clear process to get changes included in > the Policy, but this is the first time I do this, so please excuse me > for jumping all the way to "State D: Wording proposed" (of course, my > words can be checked and improved, particularly given I'm not a native > English speaker). > ⁴ https://www.debian.org/doc/debian-policy/ap-process.html > I am suggesting the following patch, which I'm attaching to this bug > report, and also uploaded them to my fork of debian-policy in Salsa: > > https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0 Thank you! I also second this change, and have merged it for the next version of Policy, including the fixes suggested by James Addison. I numbered the footnotes in chapter two so that both non-free and non-free-firmware could reference the same footnote. An editorial note: Gunnar's patch introduced non-free-firmware after main and before contrib and non-free, and after some consideration I kept that order because I think it reflects the high likelihood that the typical user will encounter the non-free-firmware archive area given the results of the GR. That does mean that the contrib and non-free sections have been renumbered to 2.2.3 and 2.2.4, which resurrects a section 2.2.4 that previously was for non-US back when we had cryptography restrictions. I don't think this will cause any actual problems (and one of my long-term wishlist items is for Policy to rely less on section numbering, which is inherently unstable, and switch to some sort of persistent ID), but it seemed worth mentioning. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
ever. We have a process for making decisions because sometimes consensus is not achievable, and the people who don't agree with those decisions may, in fact, *never* agree with those decisions. They get to do that. It's not a crime. It's also not a personal offense against you. When people voice that disagreement, again, to a decision-making body and the immediate response is for multiple members of that body to politely but quite clearly indicate that, although they're willing to listen, the discussion is probably going nowhere and no decisions will change, this is what winning an argument looks like. This is what you're going to get. You're not going to get unanimous consensus. Take the win and *leave it alone*. Right now, you keep risking undermining architectural decisions that you've worked hard to achieve because you pile into discussions with your intensity knob already maxed and say a whole lot of confrontational stuff, some of which is careless or imprecise, and then the people *who already agree with you* feel obligated to disagree and clarify. And *then you start fighting them*, and absolutely nothing about this is achieving any goal that you have. Please, for the sake of my blood pressure, I beg of you, dial it *way down*. I swear that when I do process Policy bugs I will read all the messages and understand the technical arguments and clearly state what I think the most convincing points are, and everyone will get a chance to review that, and changes can even be reverted later if we get it wrong. Nothing is going to happen by surprise, and you do not have to be the last arguer standing in order to get your change into Policy. The more messages there are, and the more emotional heat there is, the more energy the whole process requires and the longer it takes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [RFC] Extending project standards to services linked through Vcs-*
Dominik George writes: > On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote: >> This implies that Salsa is happy to create accounts for people under >> the age of 13, since the implicit statement here is that Debian's own >> Git hosting infrastructure is less excluding than GitHub. >> That's a somewhat surprising statement to me, given the complicated >> legal issues involved in taking personal data from someone that young, >> so I want to double-check: is that in fact the case? > That is, in fact, the case. > And no, it's not not legally complicated to collect personal data from > children. If we, for now, only look at COPPA and GDPR, the laws relevant > for the US and EU, respectively, the situation is: [...] Thank you! This is good to know and I'm very happy that this is the case. I'm glad people have done the research that I hadn't done and worked out what was required! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Benda Xu writes: > I take care of packages that does not meet the proposed policy. And I > don't have a systemd test environment. I am curious what is the > recommended way to go forward. > - upload a generator-converted .service without any test; > - set low-NMU to encourage interested party to upload a .service; > - leave the lack-of-systemd-service bug open until some one submit a > patch or a merge request; > - you name it. systemd unit files for "typical" daemons are very simple to write (simpler than an init script in a lot of cases) and generally don't change much. I would, if I were you, be tempted to just write an obvious and simple unit file and upload it and let people report bugs if it breaks. This isn't ideal, but at least for simple daemons the risk is probably relatively low? Maybe I'm too cavalier, though. I suspect there are also a fair number of people who would be happy to help write systemd unit files for packages, since (at least in my opinion) it's kind of fun. This isn't the right place to coordinate that, but there must be some good spot in Debian. debian-mentors, maybe? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Luca Boccassi writes: > systemd upstream will drop support for the transitional sysv generator > in the near future. The transition is long finished, it's been at least > a decade, and it's time for the tail of packages still shipping only > init scripts but not units to be updated. Has there already been a mass bug filing for packages that ship init scripts but not systemd unit files? > Tentatively this should happen within Trixie's development cycle. Of > course it's free software and generators are not that difficult to > maintain, so if someone wanted to lift the sysv generator out of the > systemd repository and adapt it to be a standalone binary there's > nothing stopping them. But I wouldn't want the systemd package to > depend on such a backward compat tool, so packages needing this > hyptothetical package should depend explicitly on it. This is just > mentioned for completeness, it's been at least a decade and writing a > unit file is beyond trivial so there shouldn't be any issue adding the > few remaining ones. > Once the policy is updated I plan to ask Lintian to bump the severity > of the existing check: > https://salsa.debian.org/lintian/lintian/-/merge_requests/407 Assuming the mass bug filing hasn't already happened and I missed it, I think this is the wrong order. This sort of large-scale breaking change should always start with a mass bug filing against all affected packages. I think the right process is: * Raise this in debian-devel and propose a mass bug filing requiring all packages to add systemd unit files if they currently only have init scripts. This gives people the opportunity to object or take over maintenance of the unit file generator and document how to depend on it if they wish to do that instead. (I don't think that's a good idea, but we should let the discussion happen.) * Unless something surprising happens in that discussion, do a mass bug filing for this transition and bump the Lintian severity at the same time. * Once that has consensus and is underway, *then* change Policy to reflect this project decision. If the mass bug filing already happened and I just didn't notice, my apologies. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Luca Boccassi writes: > I.e.: if the attached version works, then that's good enough for me. Seconded. Thank you for your work on multiple revisions of this patch! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Luca Boccassi writes: > That essentially means it's fine to use diversions and ship releases > using them, so that's exactly what will happen as per Murphy's law. I think we're reaching a consensus that "must" is appropriate for the systemd configuration files, so this discussion is about how to phrase the general guidance that isn't specific to systemd. I'm therefore not really understanding the argument that you're trying to make here. Are you trying to say that we should just delete everything in Policy that isn't a "must" because it serves no useful purpose? If not, then why are you taking this incredibly aggressive position that general guidance is pointless unless it says "must"? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > That paragraph is in the context of StateDirectory= and > RuntimeDirectory=. These are unit files options, so it's up to > alternative init systems to provide alternative and integrate them in > the (eventual) init script, just as they are defined in the systemd > unit. I've mentioned those explicitly as you indicated earlier in this > thread: Ah! Sorry, I did inded not understand the context correctly, and should have just not replied until I had a chance to read the context. That's my fault. I agree with this statement with respect to systemd unit features. This is a consequences of the fact that units are the preferred daemon configuration and package maintainers are allowed to use its features (GR 2019-002). We should be encouraging them to use those features correctly and documenting how to do so, but that necessarily means that init scripts for use with other init systems will need to provide a version of the same feature in some other way. We have had several GRs on this topic, and Policy does need to follow the outcome of those GRs unless someone overturns them with another GR. That being said: > Again, the rationale is: when there is a strong ownership model tied to > an individual service those are best as the lifecycle and permissions > are handled, when there is no owner or no specific owner or particular > metadata requirements then tmpfiles.d are best. I still am curious if it's safe to configure the same files in both tmpfiles.d and in the unit file, because it would make it much easier for those who want to support other init systems to do so. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Thorsten Glaser writes: > On Tue, 13 Jun 2023, Russ Allbery wrote: >> namely if you're running anything in a chroot that needs directories >> created in /tmp and /run, the chroot either needs to have a persistent >> /tmp and /run or you have to arrange for it to run at least some init >> scripts during boot. > I very much disagree here. Both /tmp and /run are volatile, and for /tmp > there usually even are cronjobs that delete old files, so programs that > need anything in there must create it themselves at startup (via wrapper > scripts if needed) if absent. Ah, I think I understand what you're getting at. You're talking about using the init script of a daemon as this sort of wrapper script for running it in a chroot, by invoking the init script outside of an init system as root, but inside the chroot. This works in some situations when the init script has no other dependencies, but is going to start bit-rotting because init scripts are less frequently tested and people are going to forget to add separate code to handle cases that are already handled by tmpfiles.d or the systemd unit. The replacement is to first run systemd-tmpfiles --create in the chroot and then manually run the init script as before. That does add an additional step to the (somewhat rare) case of running daemons in chroots, but it has the advantage of not having to add runtime code to every package to create directories (often incorrectly, without handling edge cases), and it's not that different from what you'd need to do to start daemons in chroots that have dependencies on other daemons. (It would also be easy to add to a generic wrapper script for starting a daemon in a Debian chroot that does this for you.) If you're just talking about programs that need temporary directories in /tmp (not /run, which is owned by root) owned by the same user that the program is running as, or programs that only run as root creating PID files in /run, then that is unrelated to this bug so far as I can tell; nothing we're talking about here changes that behavior, because nothing needs to be pre-created. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Thorsten Glaser writes: > what you described of course does not work for /tmp and /run. > It is viable for /var/tmp etc. Well, it does work for /tmp and /run as well as anything else can possibly work for /tmp and /run inside a chroot, namely if you're running anything in a chroot that needs directories created in /tmp and /run, the chroot either needs to have a persistent /tmp and /run or you have to arrange for it to run at least some init scripts during boot. My experience is that mostly the sorts of stuff that needs specific directories in /tmp and /run isn't run in a chroot, and when it is, often they just use persistent /tmp and /run. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Ansgar writes: > On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote: >> On Jun 13, Bill Allombert wrote: >>> Conversely, sometimes I need to use chroots to test init scripts. >>> start-stop-daemon should not refuse to run in a chroot if policy- >>> rc.d allows >>> it. >> I suggest that you try systemd-nspawn for this purpose. > Or podman or docker or various other things. > Plain chroots and an unclean environment which violates various > assumptions system startup scripts make are not a great way to test > stuff. Unless I'm very mistaken about how dh_installtmpfiles and systemd-tmpfiles works (possible, I guess), I don't think we need to have this argument in this bug. If I am right in assuming that nothing about this proposal will change how chroots work, arguing with people about why they use chroots is just going to add heat without any light. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
work to package a standalone systemd-tmpfiles package that can be used regardless of the init system. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Thorsten Glaser writes: > Therefore I belive that Policy ought to *not* recommend any solution > that depends on starting dæmons or init scripts to create temporary > files/directories that are necessary for programs to work. This is handled by this proposal, no? That's the point of requiring integration with maintainer scripts (via triggers or direct invocation). My understanding is that this is exactly what dh_installtmpfiles already does, via generating an explicit call to systemd-tmpfiles --create. Or am I missing something? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Sean Whitton writes: > I still find myself feeling queasy about adding this must-with-caveat. > It feels like with the caveat you're trying to get something between > "must" and "should", but then rather than build down from "must", why > not build up from "should"? I would like to propose: > Maintainers should strongly prefer using other overriding > mechanisms, instead of diversions, whenever those other mechanisms > are sufficient to accomplish the same goal. In other words, > diversions in packages should be considered a last resort. This sounds good to me. The argument for building up from should instead of down from must seems compelling. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Bill Allombert writes: > On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote: >> I prefer that too, but in this case, it feels like must is appropriate >> for at least systemd configuration files. And also, just intuitively, >> I feel like must is correct when people are using diversions rather >> than a native mechanism. Diversions add weird edge cases and we really >> shouldn't be using them lightly. >> The wording I proposed and that Luca has now adopted therefore uses >> must with a caveat. Does that sound okay to you? > I do not think appropriate for the policy to list systemd or any other > packages specifically in this section. My rationale for listing systemd specifically is: 1. This is a common case where one package wants to change the behavior of another and I expect it to become increasingly common as people make more use of systemd security features. For example, I would expect cases where the default systemd configuration for a service disallows access to large swaths of the file system, and then installing a plugin for that package grants additional access to specific paths used by that plugin. 2. We understand what people are trying to do in this case and can offer very specific guidance, whereas we can't in general for arbitrary packages. This makes Policy more useful for packagers; instead of seeing a general rule that they can't use diversions but being left on their own to figure out how to solve their problem, Policy can explicitly say "here are the mechanisms to use for this case, they can do everything you would want to do with diversions." I would like to add more documentation like this around systemd-related things to Policy because systemd is complicated and has a lot of options, so people who aren't deeply familiar with it will easily miss best practices in its reams of very good but overwhelming documentation, and Debian should be opinionated about steering people towards best practices for our primary init system, just as we were very opinionated about how to write init scripts for sysvinit. > If a package set up a diversion that breaks another, then it is buggy, > whatever policy say. If the diversion does not cause any breakage, there > is no purpose for policy to declare it a RC bug. I don't really agree with this, and I thought we had reached some agreement in the other branch of this thread that this isn't quite complete and it's okay to ban diversions if there's a better mechanism available. I think that if diversions and some other mechanism work equally well technically, we should forbid using diversions and require using the other mechanism. This is in part based on the long threads that came out of the /usr-merge discussions, which made clear that diversions are a very complicated feature with a lot of edge cases, and it's possible to get into trouble with them because they're manipulating the packaging system at a very low level. If there's some alternative that's less invasive, I do feel like using diversions is a fairly serious bug because it adds to the instability of the system. In isolation, you could talk me into it being an important bug rather than an RC bug, but that feels like a lot of nuance here and must feels cleaner and more straightforward. That being said, I'd rather back down to should than remove the systemd-specific details, since I think the latter are quite valuable. > In general, policy proscription are only useful when the description of > a better mechanism is provided. But there is no place for that in this > section. I'm not sure I understand this statement, since describing a better mechanism is exactly the point of that language about systemd. We link directly to those better mechanisms (masking, drop-ins, and, for alternatives, aliases). I definitely agree that Policy should have a whole section devoted to systemd and its configuration files, but I don't want to try to boil the ocean in one bug. But yes, we should be working towards that, IMO. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
emd/man/systemd-tmpfiles.html>`_ > +explains how to call the program so that the appropriate ``tmpfiles.d`` > +snippets are applied at the appropriate time. I don't really like being this nonspecific. Can't we just say specifically what init systems need to do? I assume it's something like "call systemd-tmpfiles --create --boot on boot and systemd-tmpfiles --clean periodically on some schedule" (what schedule?). Also, based on the previous discussion, it sounds like we should also say something about how non-systemd init systems must depend on an implementation of the tmpfiles.d mechanism. That's arguably a consequence of the requirement they integrate with it, but given that the exact dependencies matter a lot for ensuring nothing weird happens during system package installation, I think we should spell it out. > +Instead, :ref:`s-tmpfiles.d` snippets should be shipped, being ideally > +provided by the upstream sources, if any. For more details about the > +``tmpfiles.d`` interface, see :ref:`s-tmpfiles.d`. I personally lean against commenting on what upstream should do. I think any maintainer already knows that ideally as much is upstreamed as possible, it's not Policy's role to say stuff like that (that's more of a Maintainer's Guide thing), and it tends to prompt people to file weird bugs or create weird Lintian checks that are unactionable for maintainers of packages whose upstreams have no intention of providing these files for whatever reason. Policy is only about Debian packages. We're not writing policy for upstream; there's a wiki page that tries to collect that sort of advice. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Luca Boccassi writes: > There is a native alternative: aliases. We already do that today in the > archive for the well-known 'dbus' unit. The dbus package ships the > reference implementation, and dbus-broker which is an alternative > implementation ships its own unit, which also lists 'dbus.service' as an > alias. I have listed this in addition to your suggested paragraph. Thanks! This looks good to me. I've reviewed all the bug traffic and feel like this addresses the concerns, but not exactly in the way that Sean, Bill, and Sam preferred. I'd therefore like to see if this works for them or if they still feel like it's too strong before I second it. But if I were the only one deciding, I'd second this wording. (Probably not that surprising since you took all of my wording suggestions.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Sean Whitton writes: > I think what's a bit peculiar here is using "must" for a case where > there might be package-specific exceptions. In other cases, Policy uses > "should" for these cases. Typically "must" rules are simple and > completely determinate. I prefer that too, but in this case, it feels like must is appropriate for at least systemd configuration files. And also, just intuitively, I feel like must is correct when people are using diversions rather than a native mechanism. Diversions add weird edge cases and we really shouldn't be using them lightly. The wording I proposed and that Luca has now adopted therefore uses must with a caveat. Does that sound okay to you? I think must is too strong for alternatives, where I think there are more likely to be package-specific exceptions. But I'd like to take a harder line on diversions, and I do think that matches how we use diversions between two Debian packages (work around some weird situation where we have no better option). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Bill Allombert writes: > On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote: >> If you prefer, I can reword the general rule to be stricter, ie: >> "packages must not use diversions where native mechanisms are >> available" or so. Would this be better? > "native mechanisms" seems to vague. I suggested "must not be used when a suitable override mechanism that accomplishes the same goal is already available." Does that sound okay? It's a bit weaker and opens the door to arguments about whether the native override mechanism accomplishes the same goal, but I think that's a feature here rather than a bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Luca Boccassi writes: > It depends on your pain threshold. Salsa is worse for me for working on Policy in pretty much every respect than email with patches. That's not a statement about my pain threshold. It's a fundamental disagreement with you about which tools work better for this specific type of maintenance. > For me it's much easier and simpler and less painful to do all of that > on Salsa, as opposed to wade through a bunch of random emails and > scrolling up and down through the BTS. I understand that you don't like email. The Policy process is optimized for the Policy editors, rather than for the preferences of people who are working on a specific change that they care about. I appreciate that this can be annoying, but it's fairly typical for open source work. See, for example, the Linux kernel, which likewise doesn't take merge requests, no matter how inconvenient that may be for contributors. > I'm sure there were some suggestions earlier in the thread, that I now > have forgotten about, and they will be lost because there's no way I'm > going back wading through dozens of random replies to figure out what is > applied and what is not. That's fine; this is part of the job of the Policy editors. > I'm not suggesting that you stop using emails to send your changes - I'm > simply asking to reconsider making policy work like the vast majority of > other parts of Debian, and _also_ accepts merge requests on Salsa, in > _addition_ to emails. I have considered it several times, and I considered it again as part of this recent conversation before writing my reply. > Then the submitter can choose. I suspect you are going to get a lot more > contributions this way, Maximizing contribution of merge requests doesn't help the bottleneck for Policy changes. Policy changes are often complex and require thought and research. Most of the patches we get are incorrect or incomplete to start with. The bottleneck is time from people with a lot of in-depth Debian knowledge to think deeply about a problem. If the people who routinely provide detailed and incredibly useful analyses of Policy problems say that they would rather use Salsa to do so, that's important feedback and I would like to hear that feedback. But the goal here is not to maximize development speed. It's to think hard about a problem and get the answer correct. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Luca Boccassi writes: > Snarks aside, allowing merge requests to be open on Salsa in _addition_ > to attachments to the BTS, as the vast majority of other packages > already do, doesn't take away anything from you, but would add quite a > lot for the rest of us, who find ourselves very limited and very much > barrier-ized by clunky, old and painful email-based processes. Merge requests are useful when the goal is to be able to merge the merge request as-is at the end of some code review process. My guess is that this happens about 20% of the time with Policy. The other 80% of the time I tweak wording or phrasing or formatting when applying the change, and also add an upgrading-checklist entry and other bookkeeping that I don't want to have to explain to everyone proposing new wording. Policy is not a program and we're not taking source code changes. The goal of the discussion is to converge on the semantics of what we are going to say, which often requires multi-paragraph discussions where the normal tools of email such as quoting are more useful. I find trying to have an email-style discussion in Salsa to be annoying and tedious. It also fragments the record, whereas having it in the bug means I can, at any time, load the entire bug into Gnus and re-read the discussion of how we arrived at the decision in the same tool that I use for reading all other Debian discussions. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
t alternatives. I think the above rule is too strong for alternatives; it's often convenient to use slave alternatives even in places where there may be a native override mechanism, although it sounds like the systemd maintainers think this is always inappropriate for systemd. Here, I wonder if we do just want a systemd-specific rule. The systemd-specific rule shouldn't reference masking or drop-ins, though, I think, since I can't see how you would do what alternatives does using masking and drop-ins (one package would always override the other, I think, rather than allowing update-alternatives to choose between them). I think the correct observation here is that alternatives really don't make any sense for daemons. You don't want to pick between implemenations of a system service using alternatives for a few reasons, but one of the most obvious is that running update-alternatives to change the preferred implementation doesn't stop and restart the service (nor should it know to do that), so you end up putting your system in a confusing state. Therefore, I wonder if we want to just say something simpler here about alternatives: Alternatives must never be used for ``systemd`` configuration files. The alternatives system does not know how to apply changes to services when updating alternatives, so the resulting behavior would be confusing and unpredictable. I keep wanting to suggest an alternative, but I'm not sure there's an obvious alternative to suggest (the options are going to be very situation-specific), so I'm inclined to just leave it at that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Guillem Jover writes: > On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote: >> […] I suspect Policy should say something stronger and more general, >> namely that no package in Debian should divert a file from another >> package unless this is arranged cooperatively between the packages to >> solve some specific (unusual) problem. > ,--- §3.9 --- > You should not use "dpkg-divert" on a file belonging to another > package without consulting the maintainer of that package first. When > adding or removing diversions, package maintainer scripts must provide > the "--package" flag to "dpkg-divert" and must not use "--local". > `--- Oh, thank you! I had completely forgotten that we said something about this under maintainer scripts. That doesn't entirely cover this case (because systemd and udev may not be "that package" in this sense), but it covers much of the general case. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Sean Whitton writes: > On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote: >> In other words, dpkg-divert is primarily for local administrators, >> non-Policy-compliant local packages that are doing unusual things, and >> the occasional rare problem that requires special coordination between >> packages, not something that Debian packages should be doing to other >> packages without explicit coordination. >> The rule about systemd and udev files doesn't entirely fall out of that >> statement, > Hmm, could you explain why? It didn't fall out of the above statement because the systemd unit file may not be shipped with the systemd package, but by some other random package, so you could have an explicit coordination with the package that provides the unit file but still be doing something that the systemd maintainers don't want to support. I think it does fall out of the somewhat squishier statement that you shouldn't use diversions when there's some other available mechanism to accomplish the same goal. > I don't mean to dismiss the significant impact on the systemd > maintainers that's being claimed, but specifically calling out udev and > systemd configuration files seems strangely specific, for Policy, to me. I think they're a special case of the general rule that if there's some mechanism other than diversions to do what you want, you should use it instead, but it's such a common special case that we should call it out explicitly, particularly since a lot of people right now don't seem to know about masking or drop-ins. So in other words, I think I basically agree with this, but I think it's worth spending some words on systemd and udev, more as a communication strategy than anything else. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Sam Hartman writes: > In cases where the change being made is permitted by policy, I think you > have made a compelling case to vastly prefer the native systemd and udev > mechanisms to dpkg-divert. I don't think that your case is strong > enough to forbid dpkg-divert. > As far as I can tell reading your reasoning, dpkg-divert *works fine*. > It just gives surprising results to someone coming from the systemd > universe. I think (and please correct me, Luca, if I'm wrong) that Luca is trying to declare, on behalf of the systemd maintainers, that this method of disabling a systemd configuration file is unsupported and may not work. To me that does warrant a Policy "should not" even if in specific situations it works currently, because it implies that this approach is fragile and may well stop working or cause bugs in the future with no further notification (since that's essentially the definition of unsupported). Also, even apart from that, I personally would support a Policy "should not" for using diversions in any case where another mechanism is available that solves the same problem. Diversions are a low-level tool with a lot of sharp edges and should be used very carefully and avoided when there is some other approach available. > But consider a package that diverts several resources, several of them > systemd and several of them not systemd. The maintainer might > legitimately want to use the same mechanism for all the > overriding/masking so that systemd resources and non-systemd resources > were handled the same. I'm not really convinced by this the way that I would be if we were talking about alternatives. With alternatives, the slave links mean that managing a group of similar changes together is important, but dpkg-divert has no equivalent and every diversion already has to be maintained separately. Given that, I think the burden of asking people to use masking instead of diversion for systemd configuration files is a fairly minor request, so I weigh the problems on the systemd side higher than what feels like a modest convenience. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
I think your X-Debbugs-Cc was syntactically invalid and thus didn't work. I manually added in the other addresses in this reply. Luca Boccassi writes: > It has come to my attention that there is one package in Debian using > dpkg-divert to mask a systemd configuration file (an udev rule). > Speaking as one of the maintainers, both upstream and downstream, I find > this greatly undesirable for several reasons that I will outline > later. Hence I would like to propose explicitly mentioning that > dpkg-divert must not be used for systemd configuration files (units, > rules, etc), and instead the supported workflow (drop-ins, masking, etc) > must be used, both by packages and administrators. This is already > standard practice, and again there is only one instance that needs > correcting as far as I understand, and I have already provided a bug and > a MR for that [1][2]. So the impact of this policy change should be > minimal, and it's mostly to ensure more such instances are accidentally > added in the future. > I have a draft policy update, that adds a paragraph to the dpkg-divert > section of the policy. It is attached here, and also available on Salsa > on my fork [3]. The part of Policy that you edited with this patch is basically unmaintained and should ideally be removed in favor of actual Policy. (I had started looking at that a long time ago and then never finished.) All of those appendices from the old packaging manual predate better documentation maintained elsewhere (such as in the dpkg package) and are ambiguous with regards to whether they set requirements for Debian packages, document things for local administrators, or something else. The Policy manual warns that they may not be normative, and people often don't think to read them (for good reason). In the case of diversions, while I certainly agree with your proposed rule, I suspect Policy should say something stronger and more general, namely that no package in Debian should divert a file from another package unless this is arranged cooperatively between the packages to solve some specific (unusual) problem. To me, this feels similar to the case of one package modifying the configuration files of another package, where we explicitly prohibit one package modifying the configuration of another package except through an interface provided by the package whose configuration is being modified. In other words, dpkg-divert is primarily for local administrators, non-Policy-compliant local packages that are doing unusual things, and the occasional rare problem that requires special coordination between packages, not something that Debian packages should be doing to other packages without explicit coordination. The rule about systemd and udev files doesn't entirely fall out of that statement, so we can still include a specific statement about them, noting that drop-ins and masking make dpkg-divert unnecessary (and those facilities produce better tool behavior) and therefore it should not be used. So, ideally, the way I'd prefer to move forward is for us to add a new section to the main Policy manual on diversions (probably 10.11), document that this is primarily a tool for local administrators and local packages to override the behavior of Debian, and that its use between Debian packages should be rare, should involve coordination between the packages, and should only be used to solve problems that cannot be handled through other facilities such as alternatives or package-specific tools like systemd's support for drop-ins and masking. And then explicitly call out systemd and udev configuration as cases where dpkg-divert should not be used, alongside conffiles and critical system files. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug #1013195: base-files: Please add AGPL-3 license
Robert Ernst writes: > Also I kindly remark my still open questions regarding: > - Is there enough manpower in the debian policy team? No, not really. > - Who is part of the debian policy team besides of the two delegates > - Russ Allbery (rra) > - Sean Whitton (spwhitton) Currently, that is the entirety of the Policy team, although anyone can do any of the steps of driving policy changes except for the final merge and uploads (and Sean has been doing a great job getting those uploaded). I personally have been absolutely swamped with non-Debian stuff for quite some time and have managed only very rare bursts of activity. I had at one point planned out next steps for resolving all the requests to add new licenses to base-files. The root problem is that it's not clear what the rest of the project expects in terms of license inclusion in base-files, and we need to pin that down so that we have a somewhat objective criteria. That should likely be a debian-devel conversation that's actively guided to reach some sort of consensus, and I suspect some sort of straw polling would be useful since there are a lot of opinions and it's the sort of topic where we may not be able to judge the consensus of the project purely from the discussion. Things that I think need to be resolved: * What criteria should be used to decide on inclusion? Pure number of packages that use a license (plus it needing to be DFSG of course)? Or something else instead or in addition, and if so, what, and how do we judge it? If we're using number of packages, is that number of source packages or number of binary packages? * Should we include or exclude "short" licenses (by some definition of short)? At one point (if any) is a license so brief that the indirection to common-licenses is more trouble than it's worth? * What do we do about "templated" licenses whose exact wording changes from package to package? We already include one of those in base-files (BSD), which contains language specific to the Regents of the University of California, and therefore technically the BSD common-license file is arguably unusable by any package where the sole copyright holder is not the Regents of the University of California even if it has the same licensing terms. Do we rule out templated licenses entirely and not include them (except maybe grandfathering the BSD license because removing them is hard)? Is it a bug to reference the current BSD license file because of this? * If we are basing inclusion on number of packages, what's the number of packages threshold we should use? If we get consensus on those, I think we can plow through the dozen or so open bug reports about common-licenses inclusion pretty quickly, but I don't like making these decisions ad hoc about each individual license. We're long-overdue for making a project-wide decision about what does and doesn't go into common-licenses. It would probably be helpful to start that discussion with a straw-man proposal that asserts possible answers to each of those questions. That tends to make the discussion more concrete and drive more quickly to the points of disagreement. (I personally would exclude both short and templated licenses and otherwise decide purely on the number of binary packages that use a given license. I'd need to do some research on the best threshold, but my guess is that something between 200 and 500 packages would be a conservative choice.) I personally do not currently have the bandwidth to try to guide that consensus discussion. Anyone who does should feel free to use or repeat anything in this message if it's helpful. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: nocheck (don't run) vs nodoc (don't build)
Christian Kastner writes: > Policy 4.9.1 states that (emphases mine): > * "[nocheck] says not to *run* any build-time test suite" > * "[nodoc] says to skip any *build* steps" > My reading with regards to 'nocheck' was that where tests were available > and needed to be built, then they should always be built, just not run. > A typical example might be a C library package that builds those tests > and ships them as autopkgtests, maybe even in a dedicated package. > I thought this line of reasoning was sound, but then I remembered the > 'nodoc' tag and now I am no longer sure. Maybe I'm taking the 'nocheck' > description too literally. I think this may be semi-accidental stemming from the affect on build dependencies. One of the points of nodoc is to avoid needing to install (and thus have available) all the build dependencies that are used only for building the documentation, which often involves a full TeXLive installation and thus poses time, space, and bootstrapping issues. So I think we made specific note that the documentation wouldn't be built so that those build dependencies wouldn't be required. The same argument probably applies to the test suite, I think? It's just less common (although certainly not unheard of) for test suites to have test-suite-only build dependencies (as opposed to test-only runtime dependencies, which are very common in at least the Perl world). Anyway, I think this warrants a bug and some work on figuring out what we really want to say, and I'd want the folks working on bootstrapping and build profiles to weigh in. The nocheck build profile sort of implies that the test suite shouldn't be built either: No test suite should be run, and build dependencies used only for that purpose should be ignored. Builds that set this profile must also add nocheck to DEB_BUILD_OPTIONS It still doesn't say this explicitly, but it says build dependencies should be ignored, so presumably the build would fail if it required any build dependcies, implying that it shouldn't be run. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#801065: Documenting how to not fail postinst on service fails to start
Steve Langasek writes: > Therefore I think it's always wrong for a package's postinst to exit 0 if: > - it ships a service, > - it is a new install or an upgrade on a system where the service was >previously started successfully, and > - the service fails to start in the postinst. An interesting problem case is a package whose point is to run a service, but which requires mandatory and not-automatable setup before the service can usefully run. After package installation, the service cannot start. So the options are either attempt to start the service as normal in the postinst but ignore the failure, or add some more complex logic to postinst to attempt to determine whether the service has been set up properly and only attempt to start the service if it has. I think our packaging system doesn't handle this case that well. I can make good arguments for several possible behavior choices. But obviously one cannot have package installation fail because the service cannot be started when the package has to be installed so that you can configure it so that the service can start. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Request to contribute translation (zh, Chinese中文)
"M. Zhou" writes: > I was the former zh_CN translator for apt and dpkg. And I had the > exactly the same idea for translating other documents for Debian many > years ago. If I remembered what I have been told correctly, debian > policy is an very important document and is frequently updated. We have > to make sure the content can be consistently conveyed without any > discrepancy introduced by translation. Meanwhile, an out-of-sync > translated version of debian policy would also be a headache to the > policy team once made official. I think this should be okay now. Policy uses the normal translation framework, so if a part of it has been updated and the translation is out of date, I believe that section will revert to English (if I understand how the translation machinery works). That said, we haven't tried to incorporate translation work in a while, so some of the machinery has probably rusted and will need repairs. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1026231: debian-policy: document droppage of support for legacy locales
Wouter Verhelst writes: > On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote: >> Sure, but neither of those actually require us to support GBK or GB >> 18030 as a system locale, only as something that iconv() (or whatever >> browsers actually use, which is probably their own thing) can convert >> into their preferred internal representation (which is almost certainly >> UTF-8, UTF-16 or UCS-4). > Those files need to be edited *somewhere*. If that somewhere is a Debian > desktop, then you also need editors that know how to write such files, > etc. Both Emacs and vim will edit files in whatever (supported) encoding you want, regardless of the locale encoding. I would assume this is not that uncommon of a feature for other editors as well. This is therefore a bit like Simon's web browser example (although may be somewhat less transparent, admittedly). (Also, if you're editing files written in Chinese, presumably you're using an editor with good Chinese input support, and thus one that's more likely to also have good Chinese encoding support.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1026231: debian-policy: document droppage of support for legacy locales
Anthony Fok writes: > I'm not asking you to spend any time working on GB18030; that would be > the job of Debian Chinese i18n/L10n team as well as the wider community > (glibc, libiconv, Qt, etc.) All I am asking you is to maintain the > status quo, and don't discount anything other than UTF-8 as legacy. This topic comes up a lot, and I'd love to put something in either Policy or the Developer's Reference proactively to at least explain what we know about what our users need and to point people at the right questions to ask if it's been another decade and they want to standardize on UTF-8 again. Do you have an idea of something suitable we should say? I do think we probably should say more *somewhere* about making UTF-8 the default choice in most situations if you otherwise have no reason to choose anything specific. For example, as you point out, files written in Chinese for Chinese people may or may not want to use UTF-8, but at this point I do think anything written in, say, French or German probably should just use UTF-8. Also, file names in the file system shipped in Debian packages probably should use UTF-8 since there's no way to declare the character set and there are some solid reasons for picking one and sticking with it. (Obviously, users can create files with any character set they want.) > Debian already supports GB 18030-2000 (or GB 18030-2005) rather well. How do I configure a locale that uses this as the default character set? I'd like to be able to test this configuration (at least for my own packages), but since recent changes to locales it doesn't appear to be an option in debconf and I was confused trying to figure out how I should make it work. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential
Santiago Vila writes: > El 4/1/23 a las 2:32, Sam Hartman escribió: >> Why not just make all required packages build-essential? I agree we >> should fix the class of bugs you are talking about, but it seems like >> in some cases it might be easier to fix them by declaring them not >> buggy. > Because required to build != required in a _running_ system I think that's why Sam suggested making them build-essential, not essential. > The idea of declaring something not a bug to avoid fixing it is not very > appealing to me. I believe we can do better than that. I think the part that I don't understand is why we would bite off a possibly substantial amount of work to minimize the *build-essential* set. I understand why we want to minimize the essential set: we want to support tiny systems and small containers and other cases where Debian shouldn't hog a bunch of disk space. But if you are building new Debian packages, by definition you are not in a tiny minimal system case. build-essential is already somewhat arbitrary and chosen for convenience (most packages do not require a C++ compiler). Why not expand build-essential to what we're largely doing in practice to fix the consistency problem (which is a real issue) but not add work tweaking build dependencies for a bunch of packages? What benefit are we gaining from trying to push for that extra bit of minimization of *build* environments? To be clear, this is a real question, not rhetorical. It's quite likely that there is some benefit that I'm not seeing (such as with bootstrapping new architectures). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
