Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)
Guillem Jover writes: > Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields > for things that fix part of a bug, but are not intended yet to close it, > for which I use «Closes:». Ack, sorry, this was my fault. I optimistically added a bug closer when I started merging patches from this bug in the hope that we'd get them all merged before the next release and then forgot about it. (That said, and this is only personal preference and I don't feel that strongly about it, I usually err on the side of creating lots of bugs so that there can be roughly one bug per patch. It can make it a bit harder to track things if there's one bug following a bunch of semi-related but separable changes. Unfortunately, the BTS doesn't support the concept of a hierarchy with a tracking issue and a bunch of underlying implementaton issue very well.) > And for some reason I think I also got the impression, even though > the stanza changes had been committed, they could still be backed out. > (BTW I've now gone over the wiki and updated all paragraph references > that applied to stanza.) I'm personally happy to stick with stanza. > 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. I like metadata file, but I think I prefer talking about the "control member" than the "metadata part" because it more closely matches what one sees if one takes the *.deb file apart. But I haven't looked at your diffs yet. > Attached the proposals for discussion/review, and I might again have > perhaps missed instances or similar. Will take a look soon! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: new policy upload before the freeze?
Holger Levsen writes: > do you plan to release a new version of debian-policy before the freeze > in January? > I'm wondering whether I should start polishing uploads now or better > wait. I personally have vacation upcoming and am *tentatively* planning to use some of that for Policy work, but am unlikely to be able to really get started until after Christmas. I can aim for uploading the current next branch sometime during that week. I have no objections to uploading it before then; I just probably won't have time personally. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#970234: consider dropping "No hard links in source packages"
Russ Allbery writes: > The fact that this has gone unnoticed in a source package in an existing > release makes a pretty strong argument that nothing in Debian cares and > we should just remove the constraint. 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >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. -- 2.37.2
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
Wouter Verhelst writes: > On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote: >> Wouter Verhelst writes: >>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon >>> (probably after debconf though) >> Here, a couple of years later, is a patch that does this, and which I >> think is ready for seconds. > Whoops, sorry; this completely slipped my mind. Apologies, that probably sounded like I was complaining about you not sending a patch. I only meant to mention that this was a thread from a long time back, which is why it might seem out of the blue. I have dropped so many Policy balls that I'm certainly not going to complain about a bug slipping someone else's mind. :) > I think this could be expanded a bit? > "This is done to reduce the risk of inconsistencies between repeated > builds, in case a package is temporarily not available to be installed > on a given architecture (which due to the nature of the unstable > distribution might happen for any number of reasons) at the time of the > (re-)build of a package." > or something along those lines. The point is to make it clear how these > inconsistencies are caused, which I think will help with understanding. > (I realize your text is what the footnote originally said, but I think > this suggestion would improve matters) Here's an updated patch that expands that and also is more explicit, since I found my own wording a bit hard to read. I also added an example. It may be a bit verbose now, but this feels like an important topic to be clear about given how often it comes up. I also reworded the paragraph about backports to hopefully address Holger's reading. It's just trying to say that backports uses aptitude in the normal way and doesn't do anything special to transform the alternative. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 36373c7de4ae7a0ac0051848d5e1b8e181bcf78d 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 wou
Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph
Charles Plessy writes: > In the spec, the word "paragraph" is only used in the specified context, > so I always felt that there is no ambiguity. But of course, it can > create opportunities for misunderstanding when discussing about the > spec. So point taken about "paragraph", although interestingly, the > Simple English definition of "paragraph" is quite spot on if one would > replace "sentence" with "field": ”one or more sentences that are written > together with no line breaks separating them. Usually they are > connected by a single idea.” > (<https://simple.wiktionary.org/wiki/paragraph>) > The use of "paragraph" in the current spec is also consistent with > Chapter 5 of the Policy, which also uses the word "paragraph". Right, that's the motivation of this change. It didn't start as being about the copyright file, but about Policy. Guillem was standardizing terminology in dpkg. I don't have a strong opinion about what word we choose. I care more about a few surrounding principles, specifically: * We should use the same terminology when describing the copyright file as when describing Debian control files (and every other deb822 file). * Policy should use the same terminology as dpkg. * I'd prefer we not use the word "paragraph" because we also use that word to talk about normal prose paragraphs in the Description control field, and may similarly need to talk about prose paragraphs in the copyright file. > By the way, in section 5.6.26 of the Policy, the word "stanza" is also > used to mean something else than a "paragraph". Thanks, I think regardless of how we resolve this bug that usage was confusing. It was also using two terms for the same concept in the same section, since earlier the same construction was referred to as a "portion." I've fixed this to use "portion" consistently in this section. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020267: Essential packages only provide functionality after being configured
Guillem Jover writes: > On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote: >> Helmut Grohne writes: >>> […] It can be made explicit in section 3.8 quite easily: >>> Since dpkg will not prevent upgrading of other packages while an >>> ``essential`` package is in an unconfigured state, all ``essential`` >>> packages must supply all of their core functionality even when >>> -unconfigured. If the package cannot satisfy this requirement it must not >>> +unconfigured after being configured at least once. >>> +If the package cannot satisfy this requirement it must not >>> be tagged as essential, and any packages depending on this package must >>> instead have explicit dependency fields as appropriate. > Seconded. Thanks, this has been applied for the next release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5
Russ Allbery writes: > Here is a patch that I believe implements that, and which I think is > ready for seconds. Thanks for the review, both. This has now been applied for the next release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975631: debian-policy: window manager: remove reference to Debian menu
Russ Allbery writes: > I considered whether instead of starting with a priority of 40, we > should instead bump the priority if the window manager supports the > desktop specification, but I think this is a place where the structure > of X environments has changed over the years. It used to be that the > window manager was what handled application menus, but now that's > normally done by some other component of the desktop environment, or > even just some toolbar app or other type of plugin that the user has > chosen, and the window manager may be just a window manager. > Given that, I don't think there's anything useful we can say here about > menu management. Old-school window managers that don't use a desktop > environment (fvwm2, for instance) may implement support for desktop > files, or for the Debian menu system for that matter; newer ones are > likely to not handle menus at all and expect some other component to > deal with that. I just found https://bugs.debian.org/838777, which says packages that only provide a window manager without a mechanism for launching programs should not register as x-window-manager. So I'm now not sure that just removing the mention of the menu system is a complete fix and we may indeed need to say something about handling *.desktop files, because x-window-manager may really supposed to be a desktop environment. I think we can keep this change in the next release because it doesn't make anything worse, but we should probably also pursue #838777 and try to document what x-window-manager is really for in the new X world. (This is almost certainly going to require advice from the folks who work on desktop environments, since I have no idea how x-window-manager is used today.) -- 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: > On Mon, 2020-06-22 at 18:51:21 -0700, Felix Lechner wrote: >> Starting with an upcoming release, Lintian will check for the presence >> of required and recommended fields in various packaging control files. >> Our methods are probably not perfect, but it was brought to my >> attention that 'dpkg-buildpackage -S' produces *.changes files without >> 'Binary' and 'Description' fields. > This is due to a fix in dpkg 1.19.3 prompted by #818618, which brought up > an inconsistency in the handling of these fields > (commit 4a4619831de8b8972f86b489660dc98f187cfa34 in dpkg.git). DAK got > also fixed to accept these .changes files. [...] > The deb-changes(5) and policy state that these fields contain > information for binary packages being uploaded. On a source-only upload, > there are no such binaries, so the definition was internally > inconsistent. I think the only thing missing is policy clarifying that > this field is only mandatory on non-source-only uploads. Here is a patch to fix this wording in Policy. I think it's ready for seconds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From c98654d7effa875c6e11da16159ac3feded8f763 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 | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 428b8a7..f85f75d 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 ` - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory) +- :ref:`Description ` - :ref:`Closes ` @@ -809,12 +809,13 @@ 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. (``.changes`` +files for uploads containing only source packages will not have this +field.) 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. .. _s-f-Distribution: @@ -924,7 +925,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 only +source packages are being uploaded, this field will not be present. .. _s-f-Installed-Size: -- 2.37.2
Bug#970234: consider dropping "No hard links in source packages"
Helmut Grohne writes: > Jakub stumbled into the "No hard links in source packages" requirement > added around 1996 and couldn't make sense of it. Neither could Christoph > nor myself. tar does support hard links just fine. lintian does not > check this property. sugar-log-activity/38 is an example package > violating the property. It is shipped in buster and technically rc-buggy > though no bug is filed about it. > I believe that the requriement needs a rationale. Failing that, it > should be dropped. I'm inclined to agree with you on this, but it's probably worth mentioning somewhere in this bug that the AFS file system is still used and still, so far as I know, does not support cross-directory hard links because of its per-directory ACL system. I'm not sure what tar does in this situation: whether it fails or whether it just silently duplicates the file. I'm not sure that we care, but that sort of concern (along with a general dislike of hard links) is probably the original rationale. The fact that this has gone unnoticed in a source package in an existing release makes a pretty strong argument that nothing in Debian cares and we should just remove the constraint. Sam Hartman writes: > I think that hard links in a source package are fine provided that > breaking the hard links would not either break the build or provide an > unreasonable space multiplier. I agree with you that those would be undesirable properties, but are they likely and important enough to have it be worth retaining a section talking about this, as opposed to using the "not every bug is a Policy violation" rule? We do pay a (small) complexity cost for each additional requirement we put in Policy, so I'm tempted to just drop this entirely and bank the complexity reduction. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#998282: Please make Section a required field for the source paragraph in d/control
Felix Lechner writes: > The installable stanzas in d/control (called "binary package paragraphs" > in policy) inherit the Section field from the source paragraph. There is > no reason to provide inheritance the other way around. Huh, this pointed out to me that I don't know what the current behavior is. I think I've always put a Section field in the first stanza and then overridden it as necessary, or at least I don't remember thinking about this before. The current Policy description of the Section field is rather cryptic: This field specifies an application area into which the package has been classified. See Sections. When it appears in the debian/control file, it gives the value for the subfield of the same name in the Files field of the .changes file. It also gives the default for the same field in the binary packages. I understand what it's trying to say, but that's a very mechanical definition that isn't clear about the relationship between the Section field in the source stanza and the Section field in the binary stanzas. (It also claims Section is about an "application area," a term that I don't think we use anywhere else in Policy.) So, what happens today if you put Section in a binary stanza but not in the source stanza? Is it inherited from the binary stanza by the source stanza (I agree that seems weird)? If so, from which binary stanza is it inherited, if there are several? The definition of the Files field implies that the section may just be - in some cases. The current documentation certainly seems inadequate, although I'd like to understand what the behavior of Debian software is before proposing alternative wording. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
Wouter Verhelst writes: > On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote: >> Wouter Verhelst writes: >>> -policy: this is a question that has come up before >>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is >>> another example that springs to mind, but I'm pretty sure there are >>> more), so I think we should document in Policy that a) buildd only >>> looks at the first dependency in alternative build-dependencies, and >>> b) why this is the case. >> Policy already says: >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch >> permit the use of alternative dependencies, these are not normally >> used by the Debian autobuilders. To avoid inconsistency between >> repeated builds of a package, the autobuilders will default to >> selecting the first alternative, after reducing any >> architecture-specific restrictions for the build architecture in >> question. While this may limit the usefulness of alternatives in a >> single release, they can still be used to provide flexibility in >> building the same package across multiple distributions or >> releases, where a particular dependency is met by differently named >> packages. >> in 7.1. However, it's hidden in a footnote. Perhaps we should make it >> more prominant (and make it clear that it's normative), and tweak the >> wording. > Thanks, yeah, I missed that. I'll have a stab at a patch some time soon > (probably after debconf though) Here, a couple of years later, is a patch that does this, and which I think is ready for seconds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From dd30c5455f13086dd0ef90bf6890c20729a1ac0b 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 | 41 ++--- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index 5074428..f177885 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 normally used in a +restricted way. 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,27 @@ 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 interpret them in a restricted way. After +dependencies that do not apply to the current architecture are removed, +all alternatives specifying different package names than the first +alternative are dropped. (Alternatives specifying the same package name +are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) +The effect, therefore, is to use only the first alternative that is valid +on the relevant architecture. This is done to reduce the risk of +inconsistencies between repeated builds. + +The autobuilders for the Debian backports suite do not perform this +transformation and instead use the full alternatives list to resolve +dependencies. + +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, or when building it across +multiple distributions or releases where a particular dependency is met by +differently named packages. + .. _s-built-using: Additional source packages used to build the binary - ``Built-Using`` @@ -666,21 +690,6 @@ requirements to retain the referenced source packages
Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5
Guillem Jover writes: > Starting with dpkg 1.18.5, several maintainer script actions involving a > new package version, get that version as an argument after the old > version, because they could not get it in any other easy way. The new > version was only available in the new package somewhere in the > filesystem. > One previous way to workaround this limitation was to inject the new > version at build time into those maintainer scripts, which is rather > cumbersome, when dpkg already knows at run-time which new version it is > handling. > This was proposed and discussed some time ago in the debian-dpkg mailing > list. > The list of the actions and their new arguments, from the dpkg changelog > entry are: > - failed-upgrade > - abort-install > - abort-upgrade > - install > - upgrade > - failed-upgrade > Please, update the relevant section to mention those new arguments. Here is a patch that I believe implements that, and which I think is ready for seconds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 2260f7a3aafe93282860aad07b7d8c1544bcf0ce Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 18:49:04 -0700 Subject: [PATCH] new-version now passed to more maintainer scripts Starting with dpkg 1.18.5, several maintainer script actions involving a new package version get that version as an argument after the old version. Update Policy's maintainer script documentation accordingly. --- policy/ch-maintainerscripts.rst | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst index 709aabf..724074c 100644 --- a/policy/ch-maintainerscripts.rst +++ b/policy/ch-maintainerscripts.rst @@ -107,8 +107,8 @@ old version of a package that is being upgraded from or downgraded from. The ``preinst`` script may be called in the following ways: | ``new-preinst`` install -| ``new-preinst`` install *old-version* -| ``new-preinst`` upgrade *old-version* +| ``new-preinst`` install *old-version* *new-version* +| ``new-preinst`` upgrade *old-version* *new-version* The package will not yet be unpacked, so the ``preinst`` script cannot rely on any files included in its package. Only essential @@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following ways: where dependencies are only "Half-Installed" due to a partial upgrade. -``new-prerm`` failed-upgrade *old-version* -Called during error handling when ``prerm upgrade`` fails. The new package will not yet be -unpacked, and all the same constraints as for ``preinst upgrade`` -apply. +``new-prerm`` failed-upgrade *old-version* *new-version* +Called during error handling when ``prerm upgrade`` fails. The new +package will not yet be unpacked, and all the same constraints as for +``preinst upgrade`` apply. The ``postrm`` script may be called in the following ways: @@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways: the package's dependencies if those dependencies are unavailable. [#]_ -``new-postrm`` failed-upgrade *old-version* +``new-postrm`` failed-upgrade *old-version* *new-version* Called when the old ``postrm upgrade`` action fails. The new package will be unpacked, but only essential packages and pre-dependencies can be relied on. Pre-dependencies will either be configured or will @@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways: configured and was never removed. | ``new-postrm`` abort-install -| ``new-postrm`` abort-install *old-version* -| ``new-postrm`` abort-upgrade *old-version* +| ``new-postrm`` abort-install *old-version* *new-version* +| ``new-postrm`` abort-upgrade *old-version* *new-version* Called before unpacking the new package as part of the error handling of ``preinst`` failures. May assume the same state as @@ -229,7 +229,7 @@ These are the "error unwind" calls listed below. .. parsed-literal:: - new-prerm failed-upgrade *old-version* + new-prerm failed-upgrade *old-version* *new-version* If this works, the upgrade continues. If this does not work, the error unwind: @@ -305,13 +305,13 @@ These are the "error unwind" calls listed below. .. parsed-literal:: - *new-preinst* upgrade *old-version* + *new-preinst* upgrade *old-version* *new-version* If this fails, we call: .. parsed-literal:: - *new-postrm* abort-upgrade *old-version* + *new-postrm* abort-upgrade *old-version* *new-version* i. If that works, then @@ -331,13 +331,13 @@ These are the "error unwind" calls listed below. .. parsed-literal:: - *new-preins
Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages
Cyril Brulebois writes: > Russ Allbery (2022-09-19): >> but I suspect that, to the extent that this is a Policy issue, the problem >> was that a source package is not itself a udeb and therefore it wasn't clear >> whether Policy applies to source packages that only produce udebs. My gut >> feeling is that it should not: the whole point of udebs is that they get to >> break the rules. >> >> So, in addition to saying that Standards-Version is generally not used for >> udebs or for source packages that only build udebs (I would use wording >> like that rather than "required" since Policy puts no requirements on >> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes): >> >> udebs (stripped-down binary packages used by the Debian Installer) do >> not comply with all of the requirements discussed here. See the Debian >> Installer internals manual for more information about them. >> >> That could be as simple as saying "udebs (...) and source packages that >> produce only udebs do not comply" > Looks good to me, thanks! Here is proposed wording that I think is ready for seconds. From: Russ Allbery Date: Tue, 20 Sep 2022 18:35:55 -0700 Subject: [PATCH] Clarify udeb-only source packages are out of scope Note that source packages that only produce udebs are, like udebs, out of scope and may not follow all of the requirements of Policy. Say explicitly in the Standards-Version description that udebs and source packages that only produce udebs do not use Standards-Version. --- policy/ch-controlfields.rst | 3 +++ policy/ch-scope.rst | 10 +- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 428b8a7..ea8f4a3 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -540,6 +540,9 @@ Thus only the first three components of the policy version are significant in the *Standards-Version* control field, and so either these three components or all four components may be specified. [#]_ +udebs and source packages that only produce udebs do not use +``Standards-Version``. + .. _s-f-Version: ``Version`` diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst index 289c9a9..a279c26 100644 --- a/policy/ch-scope.rst +++ b/policy/ch-scope.rst @@ -71,11 +71,11 @@ Much of the information presented in this manual will be useful even when building a package which is to be distributed in some other way or is intended for local use only. -udebs (stripped-down binary packages used by the Debian Installer) do -not comply with all of the requirements discussed here. See the `Debian -Installer internals -manual <https://d-i.debian.org/doc/internals/ch03.html>`_ for -more information about them. +udebs (stripped-down binary packages used by the Debian Installer) and +source packages that produce only udebs do not comply with all of the +requirements discussed here. See the `Debian Installer internals manual +<https://d-i.debian.org/doc/internals/ch03.html>`_ for more information +about them. .. [#] Informally, the criteria used for inclusion is that the material meet -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Idea for Policy expert reviewer list
Sean Whitton writes: > I think this is a nice idea, and could help a lot with our bugs. I > think that we should do it in the lightest-weight way that we can. That > is, let's > 1) have the list > 2) write down in the README that we'll CC people at the point that >things have got sufficiently concrete, as you say > 3) announce on d-d-a that we would like people to put themselves on the >list / ask us to put them on the list. > Seems to me this could achieve everything you want to achieve without > introducing any serious bookkeeping work for anyone. (Additionally, not > sure why this would need to go to debian-devel -- seems like a Policy > team-internal thing.) Yes, good point, I'm not sure why I was thinking that we needed to discuss it on debian-devel first. Okay, not sure when I will get around to kicking it off, but I have added it to my to-do list. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph
Charles Plessy writes: > I disagree with this point of view. In my own case I had to take a > dictionary to learn what a stanza is, while the word paragraph is surely > know at least to anybody who studied English in a classroom. > In my own field, (molecular biology) we (or at least some of us) are > putting some effort to eliminate jargon and use simple words that makes > written documents more accessible to the public. This is why I prefered > paragraph to stanza when working on the specification. This is a very valid point, and I appreciate you bringing this up! My personal opinion is that I don't think jargon is necessarily good or bad. It has advantages and drawbacks. One drawback that you're correctly pointing out is accessibility: jargon can make things that would otherwise be comprehensible harder to understand. It can also be off-putting and alienating to people, and thus make it harder for them to get involved in a shared project. The advantage of jargon, and the reason why jargon exists and why humans keep inventing it, is that it's precise. You don't need as much context to disambiguate what a sentence may be talking about. I do find the use of paragraph the way we were previously using it to be confusing, particularly given that the paragraphs contain fields which in turn contain actual paragraphs in the normal sense of the term. In some contexts, precision doesn't matter, but Debian Policy is one place where we should try to be precise. Stanza has the significant drawback that it's dictionary definition is specific to poetry. In poetry, it's a close analog to how we're using it, but that does make it somewhat obscure. It does have the minor advantage of being terminology that was already in use for exactly this construction in deb822 files. I don't want to keep using paragraph, but I'd be open to some other term that Guillem was also open to (I think matching the terminology in dpkg is very important). Section or block are commonly used for things like this, but aren't very precise, so I'm not that enthused by them. > If I were to redo such a specification from scratch, I would ask > non-European language speakers their opinion too. I'm definitely interested in that opinion from anyone who is listening in! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Idea for Policy expert reviewer list
I had an idea this morning while working through the Policy backlog and wanted to see if others think it's worth pursuing. One of the challenges of some Policy changes is that there can be subtle nuances that aren't obvious. We currently rely on the seconding process to ensure that at least a few people have had eyes on any given change, but that's at the mercy of whoever happens to be reading debian-policy. Thankfully, many long-time Debian contributors have been willing to keep up with the list, but Debian is busy and traffic can be bursty and that may not always be the best use of their time. The IETF has a concept of expert review for certain types of changes, and the Linux kernel and other projects use subsystem maintainers to route patch reviews to appropriate people. I'm wondering if Policy would benefit from a similar sort of concept: maintaining a list of expert reviewers. The idea would look something like this: * We would keep a list of general Policy areas and a corresponding list of Debian experts in that area in a file in the debian-policy source package (but not part of the binary package or published on the web site). Or we put it in the wiki, but I'm trying to reduce the number of places people's email addresses get published for spamming purposes (probably futilely). * If something in that area comes up, the Debian Policy Editors would cc the experts in that area once there's a concrete proposal or patch that's ready for review. * Anyone who feels like they have deep expertise in an area of Debian and wants to be listed can just ask us and we'll add them. This wouldn't be a blocking review necessarily, since people are busy and sometimes there are expert disagreements that we still have to sort out. But the point would be to make sure the people with the highest-quality input would have an opportunity to see any change. Obviously this wouldn't be necessary for areas of Policy work that mostly correspond to a single package. In those cases (libc, for example), we should just copy the package maintainers. But there are a lot of fuzzier areas, like bootstrapping, the maintainer script execution model, shared library dependencies, the Perl policy, debconf, and so forth where I know there are domain experts in Debian but we don't have a systematic way of involving them in patch review. If all those folks are happy to read debian-policy, this is sort of pointless. I'm guessing that's not the case, but I don't really know. Guillem can also decide if he wants to be an expert reviewer on most of Policy. :) What do people think? Helpful innovation, or just extra bookkeeping that isn't worth the effort? If people do think this is a good idea, I'll bring it up on debian-devel for further discussion (and then, if we adopted it, it would be a debian-devel-announce post). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Guillem Jover writes: > Ok, I've prepared the attached incremental patch, which only switches > from paragraph(s) to stanza(s) all over the place. Thanks, applied. > I've updated all the specs for consistency. I've updated the footnote to > swap the preference and to mention paragraph is now discouraged > nomenclature. I've also updated all «id»s out of consistency, which > might break links, so I can revert that if you'd prefer. It looks like it was primarily in the copyright-format specification. I think that's fine; we haven't historically tried hard to preserve anchors, and if we ever did, we should probably use some scheme to assign stable anchors rather than using the text of the heading. > And I've preserved the (upper) casing for one of the titles > (“Stand-alone License Stanza”, although that was not consistent with the > other titles, such as “Files stanza”, I'm happy to lower case that one). I personally have been convinced by a co-worker who did the research that one should stop using title-casing in technical documents, since it's mostly a US convention, US readers don't mind lowercase, and title-casing can look weird to European readers. But that's a fix for another day. > I've gone one by one, but please review carefully as I might have > perhaps switched in excess! Reviewed, and also checked for remaining uses of "paragraph." Everything looked good. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages
Holger Levsen writes: > On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote: >> I'm fine with this change, but as Sam points out, the deeper point here >> is that Policy doesn't apply to udebs. This is the whole point of >> udebs. > When you say it like this, it sounds to strong to me, if it were written in > -policy. > .udebs are allowed to break some rules, but not all. it's not ok to put > Microsoft Word in an udeb in main. there are many other rules .debs need to > comply to. Yeah, apologies, this is just shorthand for "udebs are allowed to ignore the technical bits of Policy that don't work for them." Not that they can do absolutely anything they want. :) >> udebs (stripped-down binary packages used by the Debian Installer) do >> not comply with all of the requirements discussed here. See the Debian >> Installer internals manual for more information about them. > > this sounds good to me. Okay, great, thanks. I'll try to put together a proposed patch soon. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages
Sean Whitton writes: > On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote: >> Sean Whitton (2021-08-12): >>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote: >>>> So, it seems fairly obvious to me that Standards-Version is important >>>> for packages that produce both debs and udebs. >>>> I'm assuming the focus of our discussion then is on source packages that >>>> only produce udebs. >>>> Have I got that right? >>>> By definition, most of the policy that affects binary packages does >>>> not inherently apply to udebs. As I understand it, that's kind of >>>> the point of udebs. >>> Would you agree with this? You're only asking to stop seeing warnings >>> about S-V for source packages which produce only udebs? >> Yes, that looks good to me: source packages (also) producing debs would >> deserve a rightful nag. > I believe that we failed to consider udebs when we made the change which > made S-V mandatory. I propose we remove the requirement for S-V in > udebs and source packages producing only udebs, until and unless someone > provides a positive argument why S-V ought to be mandatory in these > cases too. I'm fine with this change, but as Sam points out, the deeper point here is that Policy doesn't apply to udebs. This is the whole point of udebs. I didn't go back and read the history of this bug, but I suspect that, to the extent that this is a Policy issue, the problem was that a source package is not itself a udeb and therefore it wasn't clear whether Policy applies to source packages that only produce udebs. My gut feeling is that it should not: the whole point of udebs is that they get to break the rules. So, in addition to saying that Standards-Version is generally not used for udebs or for source packages that only build udebs (I would use wording like that rather than "required" since Policy puts no requirements on udebs at all), maybe we should add to this paragraph in 1.1 (Scopes): udebs (stripped-down binary packages used by the Debian Installer) do not comply with all of the requirements discussed here. See the Debian Installer internals manual for more information about them. That could be as simple as saying "udebs (...) and source packages that produce only udebs do not comply" -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required
Guillem Jover writes: > This was brought up on debian-devel, and I think it needs to be > updated/corrected in the policy manual: > On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote: >> On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote: >>> Policy states: >>> "Removing a required package may cause your system to become totally >>> broken and you may not even be able to use dpkg to put things back, so >>> only do so if you know what you are doing." >> That seems wrong, or inaccurate at best. dpkg should never depend on >> anything that is not part of the pseudo-essential set (strictly >> speaking only Essential:yes + awk-virtual), or that it depends on >> explicitly. So as long as a package has not been forced out, dpkg must >> work. >> Removing a required package (that is not Essential:yes) might indeed >> render your system broken, but what broken means or in what context is >> not qualified there. This could apply to systems that get booted for >> example, but not to chroots. A package that relies on another package >> that is Priority:required and not Essential:yes, and that it does not >> depend on, is just broken. I agree with this analysis, and we shouldn't be saying things about dpkg that aren't true. What Policy says right now is: Packages which are necessary for the proper functioning of the system (usually, this means that dpkg functionality depends on these packages). Removing a required package may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing. Systems with only the required packages installed have at least enough functionality for the sysadmin to boot the system and install more software. The second paragraph seems roughly correct. The first paragraph is clearly at least partially false. What should it say instead? I'm not sure the second paragraph is enough. I feel like we should stress that you may put your system into a surprising state by removing required packages, and may have difficulties recovering because standard tools are missing, even though dpkg should continue to wrok. Do you have any suggestions for what an accurate statement would be? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020323: debian-policy: document DPKG_ROOT
Johannes Schauer Marin Rodrigues writes: > * where to document this? Other variables set for maintainer scripts >like DPKG_MAINTSCRIPT_PACKAGE or DPKG_MAINTSCRIPT_ARCH do not seem to >be documented either even though (according to codesearch.d.n) they >are used in hundreds of places In general, Policy doesn't need to be a copy of dpkg's documentation, so I don't think we need to list everything that dpkg makes available. The important thing that Policy is adding isn't to catalog the facilities available. It's to tell you *when* to use those facilities. In the case of some of those variables, that's the obvious "whenever it's convenient to get that information from an environment variable for whatever you're trying to do," and Policy doesn't need to say anything about it. But here, some packages *have* to use this environment variable or they will be buggy. That's the sort of thing Policy should describe. I would tend to add a section on bootstrapping support (since that's what this is for) to chapter 6 at the end. It could just talk about DPKG_ROOT for now and we can add any other maintainer script considerations that come up there in the future. > * what about scope? The Essential:yes and build-essential package set >are certainly a *must*. We need these to start building natively on a >new architecture. But do we need more than those? Having apt would be >handy but not strictly necessary (dpkg -i can always be used >instead). Having an init system would be handy but not strictly >necessary (can always boot with init=/bin/bash). I think this is up to you to define, but we need to be able to describe it. Starting with essential and build-essential packages sounds great, and Policy already defines both of those terms, so that's easy. If you need to add more packages, we will need to figure out how to describe them without special-case listings of package names. > * what can maintainer scripts supporting DPKG_ROOT expect from the >system on the outside? Are its package versions the same as the >system inside the chroot? Is it even Debian? Right now we do all our >tests such that the system on the outside is identical to the one we >want to create the chroot for except that it is of the native >architecture. But should such a restriction be placed in policy? It sounds like you're not imposing any restrictions on the *package* here, so there's no need to say anything unless at some point you need to do so. The point of putting this in Policy is to provide guidance to the packagers, not to the bootstrappers. Presumably you already have other documentation that you maintain about how to bootstrap Debian that spells out what to do in what order; that's outside of Policy's remit. What Policy is trying to do is to define for packagers what interface they have to implement, and DPKG_ROOT is now part of that interface. So in other words, you can just say something like: Maintainer scripts in essential or build-essential packages must preface all paths they act on in maintainer scripts with an expansion of the DPKG_ROOT environment variable. This will normally be empty (and thus normally will not change anything), but in some situations it may be set to a bootstrapping path to tell packages to act under that path instead of on the root file system. That wording probably isn't quite right, but I think that's the general idea. > * what about upgrades? We only want to create a chroot and some of our >patches are made much simpler because we ignore upgrades. If newer >package versions are required, the bootstrapper can just create a new >chroot without upgrading anything. If maintainers don't have to worry about this for upgrades, you can just say so. I think it's up to you whether you think that is important or not. I would be inclined to say that it's *safe* to add DPKG_ROOT to paths even on upgrade actions, but you only *must* do so for maintainer script actions that run during initial installation. Thank you very much for starting this discussion! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
Ansgar writes: > There is an updated version (RFC 5322) that should be used instead. > Notably RFC 5322 is more restrictive on the local part (whitespace and > escape sequences are no longer allowed except as obsolete syntax). > Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in > local parts (and other places). That should probably be allowed as > well. > So, Policy should probably: > - Refer to RFC 5322. > - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax"). > - Allow the extensions from RFC 6532. I agree with this as a general direction. I think we could probably just make the first and third changes without much trouble; my recollection that not much was dropped between RFC 822 and RFC 5322 and the stuff that was is highly, highly unlikely to be in use. We're also quite safe in dropping the obsolete syntax in RFC 5322. No one is using source routing in email any more (I don't think it's worked on a running mail system in decades), and I very much doubt anyone is using CFWS in debian/control files in that way. The only time I used to see that was with people mangling addresses for dubious spam protection, which we don't allow in Debian anyway. I understand Bill's concern, but I'm not worried about it here; the obsolete constructs are quite obsolete. So, wording implementing the above three points is welcome. As for your follow-up message to this bug, for better or worse Debian pretty strongly assumes the "Full Name " syntax and I'm not sure we should expect people to allow the full RFC 5322 syntax. In particular, you suggested name-addr, which is: name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr but we absolutely do not support CFWS (for those not familiar with RFC 5322, this is comment folding whitespace), only FWS. display-name has a more obscure problem, which is that it allows quoted strings, but I'm fairly sure that Debian software would break if we tried to allow all the things that RFC 5322 allows inside quoted strings, and we also would prefer people not use quotes if they're avoidable because not all of our software deal with them correctly (and they're usually unnecessary). The main exception is if a person's name contains a comma, which we deal with quite poorly and which we probably should fix, and allowing quotes in that case is probably the right fix, but it's also probably a difficult fix for a lot of deb822 parsers. In other words, I'm in general on board with aligning with the latest email standards, but I don't want to take that so far as to allow unnecessary and rather baroque constructs we don't currently permit in practice just because they're allowed in email headers. We should go stricter if anything, not more lenient. Similarly for Uploaders, in practice it should be a comma-separated list of the same syntax as Maintainer, and we don't want to use constructs that introduce the possibility of comments. We certainly don't want to support groups, which we've never allowed and which are quite obscure even in RFC 5322. For those who have never seen them, a group looks like: Some Name:r...@debian.org,ea...@eyrie.org; This has been formally supported in email since the beginning even though essentially no one ever uses it. About the only time you ever see a group in practice is the empty group in: Undisclosed Recipients:; which shows up from time to time. There is some definite merit to using the ABNF productions in RFC 5322, but it's tricky to do because RFC 5322 allows comments almost everywhere, and we allow comments basically only in display-name (and in display-name don't even treat it as a comment, but instead as part of the person's name). So, in short, definitely open to patches here, and I agree that the current Policy specification for Maintainer is both underspecified and somewhat obsolete, but I think the patches should be conservative and not introduce the stuff that RFC 5322 allows in headers but that we currently don't support. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Russ Allbery writes: > The killer features of YAML for the purposes of the copyright format are > the > and | symbols after a key, which let you write paragraphs of text > afterwards with normal structural indentation and full editor support > for wrapping and the like, and you can choose whether you want > significant whitespace. I said I wasn't going to get into this, but of course now I can't stop thinking about it. For those who haven't done very much with YAML, an example may help illustrate what I'm talking about. Here's the copyright file for libpgp-sign-perl, which is fairly simple, converted to a hypothetical YAML syntax. I moved the Expat license to a separate license stanza to illustrate how that would work, and I also made up some structure to represent a bunch of the things we put into a copyright-format file as plain text right now that we could turn into less ambiguous fields. The latter we can of course do in the current syntax, so that's not the interesting part; the interesting part is to look at what's required to represent the structure, how much nested structure you can add, and how the text blocks are handled in the format. There is also an illustration of how to handle long copyright lines in here. Note that YAML syntax and schema checkers are also quite common, so we can easily provide tools to validate these files without writing bespoke parsers the way that I did for Lintian with the current syntax. I'm erring on the side of very unambiguous nested structure here and avoiding any implicit semantics, which may be overkill; we could tone that down quite a bit if we wanted in the name of making the file less complex. (Or we could go a step further and split the years from the holder in copyright statements, but that feels like overkill even to me.) Also try saving this as a file ending in .yaml in your favorite editor, if you haven't done a lot of YAML work before, and see how well it handles it for syntax highlighting, editing, etc. Emacs handles it extremely well with elpa-yaml-mode installed. vim, at least without any add-ons installed, does some syntax highlighting but is still a bit confused by the text blocks and thinks colons are significant in them. (There's apparently a vim-yaml plugin that I don't have installed that might help there.) format: https://www.debian.org/doc/packaging-manuals/copyright-format/x.x/ upstream: contact: Russ Allbery source: urls: - https://www.eyrie.org/~eagle/software/pgp-sign/ files: - paths: [*] copyrights: - 1997-2002, 2004, 2007, 2018, 2020 Russ Allbery license: identifier: Perl grant: | This program is free software; you may redistribute it and/or modify it under the same terms as Perl itself. This means that you may choose between the two licenses that Perl is released under: the GNU GPL and the Artistic License. Please see your Perl distribution for the details and copies of the licenses. pointers: - /usr/share/common-licenses/GPL-1 - /usr/share/common-licenses/Artistic - paths: - t/data/perlcriticrc - t/docs/pod-coverage.t - t/docs/pod-spelling.t - t/docs/pod.t - t/docs/spdx-license.t - t/docs/synopsis.t - t/lib/Test/RRA.pm - t/lib/Test/RRA/Config.pm - t/style/coverage.t - t/style/critic.t - t/style/minimum-version.t - t/style/obsolete-strings.t - t/style/strict.t copyrights: - >- 2011-2014 The Board of Trustees of the Leland Stanford Junior University - 2015-2016, 2018-2020 Russ Allbery license: identifier: Expat - paths: [t/data/perltidyrc] copyrights: - >- 2012-2013 The Board of Trustees of the Leland Stanford Junior University license: identifier: all-permissive text: | Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty. licenses: - identifier: Expat text: | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover writes: > I think Disclaimer and Comment do not seem as problematic because they > tend to contain descriptive prose. For Source it's true that it's weird > as it seems to indeed want to have two different semantics depending on > the content, and considering the current deb822 format, perhaps having > used two different field names might have been better as you alluded > with your YAML example, say Source-Urls (line-based list), and > Source-Comment (formatted text). Such split still seems feasible and > backwards compatible right now though. Yes, good point. > Just to try to clarify to make sure we are on the same page (if we are, > sorry for the obvious!). What I find confusing is that the semantics of > the field imply different line-wrapping semantics depending on leading > spaces, and because there's no synopsis, the first line is supposed to > act just like the rest, but if spaces are ignored, then how do you > select either of the line-wrapping behaviors for the first line? Also > because adding such spaces after the colon look like typographic errors > to me somehow. Ah, I see what you're getting at. I was distinguishing between spaces on the first line and spaces on subsequent lines and assuming that if you wanted to mark the first line as verbatim you would have to have a newline first. Now that you point it out, it's clear that my brain has a fairly complicated assumed semantic model here that isn't at all clear from the description of the field and may not even be the right thing to do. > So I think what seems most confusing to me is that for formatted-text > fields with no synopsis, the first line is being used at all, because > that messes with the intuition on how the Description field operates. Yes, this makes sense. Maybe we should encourage people to not use the first line? (Prohibiting it is presumably too much of a compatibility break to be worth it.) > I was thinking that perhaps an easy way out, might be to say that if the > field contains an empty first line (nothing after the colon), then it's > line based, otherwise it's considered formatted text. Which makes things > more complex (perhaps "only" for a transition period), but might be > considered backwards compat? This sounded promising but unfortunately I think Wouter identified the issue, which is that if we're defining extra leading whitespace as indicating a continuation line (which is a somewhat natural thing to do in a format based on RFC 822 header fields), this changes the semantics of any existing Copyright fields that happen to have skipped the first line but are using extra indentation to indicate verbatim lines. I think I'm talking myself into introducing a new Copyright-Lines header as the best theoretical fix, although that will be quite annoying for Lintian and any other tool that currently parses the file, since any file in the new format is going to look entirely invalid. I knew the backward compatibility issues were going to be a whole can of worms. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Wouter Verhelst writes: > On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote: >> Yes, we should distinguish between formatted text with synopsis and >> formatted text without synopsis more clearly. Or, you know, just >> propose a new YAML format which would make it trivial to clean up all >> of these problems *and* would provide first-class editor support and >> easy parsing in every major programming language. :) But that's WAY >> bigger than this bug. > If we're going to do that, it might make sense to explicitly allow JSON > and/or TOML as alternative representations, because there are some > really weird edge cases in YAML. I don't want to get too far into this since I don't think we're realistically ready to propose such a thing, but I spent a bunch of time researching this for my static web site generator, and YAML is the best of a bunch of bad options for precisely the kind of structured data we want to put in the copyright file. While I agree that most of the YAML specification was a mistake and I really wish someone would produce a reduced spec, there's a sad shortage of other widely-implemented syntaxes that are usable for files intended to be read and written directly by humans, particularly ones containing large blocks of text. JSON is definitely not it; JSON is a great computer interchange format, but I tried to use it for something complex and human-editable and I would never do that again. Too much fiddling around with quotes and commas and escaping, and for the copyright format, the obvious problem that JSON has no way of representing blocks of text that isn't horrible. (That said, if the file is YAML, you are allowing JSON, because all JSON is valid YAML since YAML allows JSON as alternative syntax. Yes, yes, the specification is a sprawling mess.) TOML looked for a while like it was going to be the format I was hoping for, but they implemented nested dictionaries in a way that makes the format incredibly annoying to use for anything that has nested structure. More relevant to the copyright file, while it at least has multiline literal strings, they're awkward to read and write, particularly in nested structure, compared to YAML. If you don't want the leading whitespace of indentation to be significant, you have to put a backslash at the end of every line, which is really not okay. And unfortunately TOML is incompatible with YAML, unlike JSON, so to support both you have to embed both libraries and select which one to use, which is annoying. The killer features of YAML for the purposes of the copyright format are the > and | symbols after a key, which let you write paragraphs of text afterwards with normal structural indentation and full editor support for wrapping and the like, and you can choose whether you want significant whitespace. YAML also has excellent implementations for basically every programming language and editor, which is mostly true of JSON and kind of true of TOML and stops being true after that. Yes, the spec is a disaster, but since other people have already implemented it for you, including with protections against the more dubious stuff, you don't have to care as long as you don't creep into the dark corners when writing files. I understand Guillem's desire to not make dpkg depend on a YAML library, and we should stick with deb822 with anything that is required at that level, but the copyright format is optional and from dpkg's perspective is just an opaque file, so that's probably not a blocker. > I think semantic versioning would require you make this a major version > bump, since like you say it's not backwards compatible. Yup. > Ah yes, but then if you do that, the old examples in policy that were > being patched away here (usage of which might exist in the wild) would > now have different semantics... Yeah, it's a mess. Maybe the right solution is to introduce a new Copyright-Lines field with the semantics we want and deprecate Copyright. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#830913: debian-policy: Allow amd64 systems without /lib64
Javier Serrano Polo writes: > Some amd64 systems do not have /lib64, although they can run programs > with the interpreter set to /lib64/ld-linux-x86-64.so.2 . It would be > nice if Debian could allow such systems. In section 9.1.1, where it > says: > The execution time linker/loader, ld*, must still be made > available in the existing location under /lib or /lib64 > "must" should be "should". You reported the above bug six years ago, and it looks like it never received a reply. I'm sorry about that! I'm confused by this bug report, though. What does "some amd64 systems" mean in this context? It looks to me like the amd64 libc6 package provides /lib64/ld-linux-x86-64.so.2, so a Debian amd64 system would satisfy this. Is there some alternate libc6 package available in Debian that does things differently? Or are you thinking of some sort of container or other type of restricted system? Also, in this case, how does this work? Is the path somehow remapped at the kernel level? (If so, I'm wondering if that would qualify as "made available" for the purposes of Policy anyway.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax
"Daniel Shahaf" writes: > Here's a revision of the patch incorporating the feedback so far: Thank you for this patch! I confirmed that your description matches the regular expression. This has now been applied for the next release of Debian Policy. > [[[ > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 1d870d9..1c71525 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -151,9 +151,9 @@ used here to separate groups of changes, if desired. > If this upload resolves bugs recorded in the Bug Tracking System (BTS), > they may be automatically closed on the inclusion of this package into > the Debian archive by including the string: ``closes: Bug#n`` in > -the change details. [#]_ This information is conveyed via the > -``Closes`` field in the ``.changes`` file (see > -:ref:`s-f-Closes`). > +the change details, where ``#n`` is the bug number. [#]_ This > +information is conveyed via the ``Closes`` field in the ``.changes`` > +file (see :ref:`s-f-Closes`). > > The maintainer name and email address used in the changelog should be > the details of the person who prepared this release of the package. They > @@ -860,10 +860,19 @@ should not exist a file ``debian/patches/foo.series`` > for any ``foo``. > > /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i > > - Then all of the bug numbers listed will be closed by the archive > + That is: The string should consist of the word ``closes:`` followed by > + a comma-separated list of bug numbers. Bug numbers may be preceded by > + the word ``bug`` and/or a ``#`` sign, as in > + ``Closes: 42, bug#43, #44, bug 45``. > + > + The list of bug numbers may span multiple lines. > + > + All of the bug numbers listed will be closed by the archive > maintenance software (``dak``) using the version of the changelog > entry. > > + The words ``closes:`` and ``bug`` are not case sensitive. > + > .. [#] > In the case of a sponsored upload, the uploader signs the files, but > the changelog maintainer name and address are those of the person who > ]]] -- 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: > I would like to recommend packages to use tmpfiles.d(5) to manage > creating directories in locations such as /var or /etc instead of > maintainer scripts. > It could also be used to create trivial files below /var that should be > recreated if deleted by accident (such as atd's sequence number which is > currently created by the maintainer script). Hi all, Here's where I think we currently are with this proposal: * There should no longer be any blocker to adding a dependency on systemd-tmpfiles since systemd-standalone-tmpfiles exists. * So far as I can tell, dh_installtmpfiles adds the correct stanza to the postinst script for a service to run systemd-tmpfiles after the package has installed its tmpfiles.d fragment. I believe that addresses creating these files on installation on systems without any init system? (Obviously if tmpfs file systems are subsequently reset on such a system, there is nothing in place to recreate these tmp files, but I think that's expected and not something we can address?) * Guillem plans to add support to dpkg to register these files properly as package-associated files and also handle creation of the files. This is great, and I am 100% in favor of it. I don't think that blocks this change; to the contrary, I think this change is a good incremental step towards that world, since it moves temporary file creation out of maintainer scripts into a declarative syntax. dpkg can then either consume the same syntax or packages can later convert that syntax to whatever dpkg uses, depending on how the dpkg implementation works, which will be a simple and easy-to-detect migration that Lintian can diagnose. Therefore, I don't see anything blocking adopting this as a policy now, and it seems like an obviously good idea to me. Am I missing something? If not, I think the next step is for someone to propose wording. In order to handle installations that have no init system, I think we may have to require that the dependency be listed as: systemd-standalone-tmpfiles | systemd-tmpfiles to avoid trying to install systemd into an init-free chroot. Maybe I have that wrong? Currently, dh_installtmpfiles doesn't add a dependency at all, probably because it assumes that the package will use a fallback to create the files in cases without an init system? Either way, we should address this in the Policy wording, and then encode that in dh_installtmpfiles if needed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#924401: base-files fails postinst when base-passwd is unpacked
Control: reassign 924401 base-passwd,base-files Control: clone 924401 -1 Control: reassign -1 Essential packages only provide functionality after being configured Control: tags -1 patch Hi all, Trimming the recipient list to just the relevant maintainers and those who proposed and (I believe) seconded a change. This is a very long bug with a *ton* of very useful information about bootstrapping Debian that I hope someone will capture and document somewhere, but after reviewing the whole thing, I believe there is only one actionable change for Policy buried in the middle of it. It's also currently assigned to three different packages, and I certainly don't feel entitled to close the broader issue by applying that change. Therefore, I'm going to remove debian-policy from this bug, and create a new bug to handle just the proposed Policy change discussed below. (For what it's worth, I love Guillem's idea of converting more maintainer scripts into declarative metadata and getting out of the problen that way.) Helmut Grohne writes: > I think at least Guillem and Santiago were arguing that policy should > not be applied to bootstrap. While I don't like that view, I do find it > reasonable. It can be made explicit in section 3.8 quite easily: > Since dpkg will not prevent upgrading of other packages while an > ``essential`` package is in an unconfigured state, all ``essential`` > packages must supply all of their core functionality even when > -unconfigured. If the package cannot satisfy this requirement it must not > +unconfigured after being configured at least once. > +If the package cannot satisfy this requirement it must not > be tagged as essential, and any packages depending on this package must > instead have explicit dependency fields as appropriate. This change looks correct to me based on the discussion in the bug but I don't know enough to independently confirm that. I believe Santiago effectively seconded this change in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924401#91 It needs one more second. Ideally, I'd like this to be someone else who has a lot of understanding of the semantics of essential packages (Guillem, for instance). Alas, due to the ordering of the BTS actions, you may have to hunt down the cloned bug against debian-policy to second it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975631: debian-policy: window manager: remove reference to Debian menu
Ansgar writes: > Section 11.8.4 "Packages providing a window manager" still references > the Debian menu. But the Debian menu is deprecated. > I suggest to remove the reference, for example with the patch below. > --- a/policy/ch-customized-programs.rst > +++ b/policy/ch-customized-programs.rst > @@ -345,13 +345,7 @@ Packages that provide a window manager should declare in > their > alternative for ``/usr/bin/x-window-manager``, with a priority > calculated as follows: > > -- Start with a priority of 20. > - > -- If the window manager supports the Debian menu system, add 20 points > - if this support is available in the package's default configuration > - (i.e., no configuration files belonging to the system or user have to > - be edited to activate the feature); if configuration files must be > - modified, add only 10 points. > +- Start with a priority of 40. > > - If the window manager complies with `The Window Manager Specification > Project <https://www.freedesktop.org/wiki/Specifications/wm-spec>`_, Yes, this looks right to me. Seconded. I considered whether instead of starting with a priority of 40, we should instead bump the priority if the window manager supports the desktop specification, but I think this is a place where the structure of X environments has changed over the years. It used to be that the window manager was what handled application menus, but now that's normally done by some other component of the desktop environment, or even just some toolbar app or other type of plugin that the user has chosen, and the window manager may be just a window manager. Given that, I don't think there's anything useful we can say here about menu management. Old-school window managers that don't use a desktop environment (fvwm2, for instance) may implement support for desktop files, or for the Debian menu system for that matter; newer ones are likely to not handle menus at all and expect some other component to deal with that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#991984: Please document minimal environment variable needed for sensible-utils
"Bastien Roucariès" writes: > Dear Maintainer, > For now $env -i sensible-utils, fail due to $HOME and $TERM not set. > I am for now working around HOME not set in sensible-utils core, but > posix [1] documentation does not document really the value that should > be set for a correct behavior of program. > Nevertheless: > - we should expect that PATH is set to a sensible value (note that it depends > of the shell), but nevertheless not setting PATH is not really safe > - HOME may not be set. If set the value may be incorrect (su -) > - TERM may not be set. If set the value may not be correct > - USER may not be set. If set the value may be incorrect (su -) > So I will like to have a footnote saying that > sensible-pager/sensible-editor etc, should test if they work under env > -i, and if they do not work fallback to return 126 (according to shell > documentation Command invoked cannot execute), thus allowing > sensible-utils to fallback to vi that is safe and tested under env -i I think it is a fine idea to attempt to support those situations in sensible-editor and sensible-pager and document them there, but I'm not sure what Policy change you're asking for here or why this would be a matter for Policy. Policy does not mandate any specific behavior for sensible-editor and sensible-pager other than that they will implement the EDITOR and PAGER environment variable checking for you. I think that's best left to the maintainer of those programs to decide. We also don't expect that the editor or pager invoked following the rules in Policy 11.4 (and, by extension, sensible-editor and sensible-pager themselves) will work in unusual situations, such as ones without standard environment variables set. We can't: the user is free to set EDITOR and PAGER to anything they chose, including programs not in Debian. So you can't really expect any particular behavior from whatever EDITOR or PAGER is set to. Maybe it will fail with a helpful error code, maybe it will start and not work but not exit, maybe something else entirely will happen. This is really outside of our control. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover writes: > No problem. Then in that case I guess I'll try to prepare/commit such > revert patches for the tooling during this week or so. For whatever it's worth, I'm not sure that I would bother, even though I share with you the general desire to be correct about things like this. While semantically such fields are incorrect according to the specification, in practice I don't believe any format-aware reader exists. The files are read by humans or by scripts that likely don't care about this fine distinction. As evidence, I note that no one had previously noticed that this formatting is technically incorrect. I think it would be fine to leave them and have this be fixed by a future format change, even if it takes a while. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover writes: > On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote: >> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote: >>> Russ Allbery writes: >>>> I would happily apply a version of 0002 that only changes Files and >>>> leaves Copyright alone. >> I can split that up, for an incremental update yes. Will send later. > Attached. Thanks, applied. > BTW, just to make this clear, if this feels like it might not be decided > quickly on the Debian policy side, then I'll prepare/commit changes to > revert this behavior from tooling that I've previously introduced, until > and if this changes again. Otherwise if the feeling is that this might > get decided quickly, then I'd prefer to avoid the flip-flopping behavior > change (but not to be taken as "current-practice" pressure to swindle > the decision! And I'm happy to do it in this case anyway if that makes > people feel better about it). I have an entirely unpredictable schedule for Debian work, unfortunately, so I truly don't have any idea how long this will take. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover writes: > Oh! I've completely missed this all this time, I think because that > feels very weird given that it has no synopsis and the text is added > already on the first line on the spec. :/ Other formatted fields with the same semantics are Source, Disclaimer, and Comment. I don't think there are any fields in debian control files with those semantics (Description is the only formatted field and it has a synopsis), but there are several of them in copyright files. Source is another ongoing minor problem, since it's *usually* a URL but is not required to be one, and sometimes a textual description of the source is needed. Here too, a structured format would have been nicer, so that you could have something like: source: urls: - https://example.com/foo - https://example.org/foo comment: >- The foo-rewrite script was originally posted to comp.unix.sources in 1992 but otherwise has no source other than the Debian package. Ah well. > Right, the problem I see is that applying this formatting to a field > that has no special treatment for the first line just after the field > name seems very unintuitive, because the first line does not contain an > additional prefixing space, or if it does no one is adding it! > It feels very weird to me that all these would be equivalent: > Copyright: Something long that might trigger some wrapping behavior > Other thing very long that might not be clear behaves as the above > More > and > Copyright: Something long that might trigger some wrapping behavior > Other thing very long that might not be clear behaves as the above > More > and > Copyright: > Something long that might trigger some wrapping behavior > Other thing very long that might not be clear behaves as the above > More I think my brain just assumes that all whitespace after the colon of a field name and before the first non-whitespace character is ignored, so doesn't have a problem with that, but I can see why it would be confusing. > Otherwise, if the current semantics are retained, at least for me, the > first line behavior really needs to be clarified. Yes, we should distinguish between formatted text with synopsis and formatted text without synopsis more clearly. Or, you know, just propose a new YAML format which would make it trivial to clean up all of these problems *and* would provide first-class editor support and easy parsing in every major programming language. :) But that's WAY bigger than this bug. > If we end up switching the field semantics, that seems it might cause > unnecessary modification churn, given that I (not sure whether other > people have done this before than me as well) at least have "instigated" > unintentionally this type of change in several places (packages I > maintain, golang/prometheus team), including tooling (AFAIR dh-make and > dh-make-golang), and other people might have also picked this up too. :/ I think making the field a line-based list is the obviously correct thing to do. It's just not backward-compatible, so we will have to face the question of how we handle a version bump in the copyright file (and of course figure out if we're going to deal with all of the other requests that would require a version bump). And I have packages where individual copyright lines are longer than 80 columns, so we either have to require unwrapped lines greater than 80 columns (which I'd rather not do), or we have to define line wrapping semantics for line-based lists, which adds yet more irritating ugliness to the deb822 format. Probably just "if the line is indented by more than one space, it's a continuation for the previous line" I guess. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Guillem Jover writes: > I've been considering naming debian/control something like > «Debian template source package control file», as that is used to > generate both the source and binary control files. And always > prefixing with Debian, so that would end up as: > * debian/control: «Debian source package template control file» > * .dsc: «Debian source package control file» > * DEBIAN/control: «Debian binary package control file» > This also removes the «master» usage in dpkg, for me for the same > reasons as I covered at > <https://lists.debian.org/debian-dpkg/2021/03/msg2.html>. I like this. It took a bit for my brain to adjust to it because "template" felt wrong, but the more I thought about it, the more I think that's correct and it's pointing out an error in my default way of thinking about packages. > File contents > - > We have references to the various parts being called as «paragraphs», > «stanza», «blocks», but this seems to be more of an issue with dpkg, as > the usage in the Debian policy is quite clear and uniform now, so I'll > at least try to remove the «block» usage there, stanza has the nice > property of being shorter and policy already mentions that this is > currently a common alias, so I might keep paragraph and stanza for now > in dpkg. > The other thing affecting dpkg and debian-policy is how the parts > within the control files are referred to. We have for example: > dpkg → «general section of control info file» >«source stanza» > policy → «general paragraph» > dpkg → «package's section of control info file» > policy → «binary package paragraphs» > So, how does «source package paragraph» and «binary package paragraph» > (of the «template control file») sound instead? As mentioned in the other thread, I think source package stanza and binary package stanza (of the template control file) sound great. Obviously a patch to Policy would be delightful, but it's not blocking. Just let us know if that's more than you have time for. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Sean Whitton writes: > On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote: >> So, personally, I'd be happy to fully switch to stanza TBH, because it >> seems more specific to our use, probably easier to search for, and >> it's shorter. > I think this is fine for Policy to do. I vote for switching to stanza. Paragraph is going to be confusing when talking about package descriptions, which often have multiple paragraphs in the normal English meaning of the term. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020243: debian-policy: Use OpenPGP instead of PGP
Guillem Jover writes: > Another minor patch I had laying around, switching references to the > OpenPGP specification instead of to the specific PGP implementation. Thanks, applied. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Russ Allbery writes: > I would happily apply a version of 0002 that only changes Files and > leaves Copyright alone. Or, perhaps even better, one that changes Copyright the way that you did, but just adds an extra space. I think that's the simplest compromise between what you're trying to accomplish and the field definition. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover writes: > These are the set of changes I keep doing to the debian/copyright files > I end up touching. While some could be characterized as a subjective > style issue, I've tried to give as close as possibly objective :) > rationale for every and each of the changes in the commit messages which > I'll summarize here. Thanks! I have applied these changes for the next release except for patch 0002 (applying wrap-and-sort -sat). I agree with patch 0002 for Files, but unfortunately I believe it's incorrect for Copyright. You're treating Copyright as if it were a line-based list field, but for better or worse (I think probably for worse) the current specification says that it's a formatted field. This means that your change to, for example: Copyright: 2008 John Doe 2007 Jane Smith 2007 Joe Average 2007 J. Random User means that the semantic content of that field is now: 2008 John Doe 2007 Jane Smith 2007 Joe Average 2007 J. Random User and a format-aware display engine should show it as such. This is the reason why lines are indented: that makes them verbatim lines per the formatting specification in https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-description I would agree with changing the definition of Copyright to a line-based list, although in order to do so we'd have to figure out the implications of a format change in the specification, and we should also flesh out the definition of a line-based list to explain how to handle a line that's longer than the normal wrap length. (In retrospect, I really regret not supporting YAML as the syntax for this file. I know YAML has a lot of problems, but it provides an unambiguous representation of constructions like this, whereas deb822 has a lot of gaps.) I would happily apply a version of 0002 that only changes Files and leaves Copyright alone. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1020238: debian-policy: Spacing an typographical cleanups
Guillem Jover writes: > I'm attaching a few patches fixing spacing and typographical issues. > For the quotes fix, I personally highly prefer UTF-8 character pairs > such as «», “”, ‘’, but went with the conservative ASCII ones '' as that > tends to cause less opposition. But I'm happy to convert these to some > of the UTF-8 ones if you prefer. Thank you! Applied for the next release. I have a minor bias against the UTF-8 quotes only because they're more annoying to type with a typical US keyboard, while agreeing that they're typographically more correct. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#696185: [copyright-format] Use short names from SPDX
Simon McVittie writes:
> Sorry, (c) seems very unlikely: earlier versions of SPDX had the same
> convention as DEP-5, but later versions moved to "GPL-2.0-only" and
> "GPL-2.0-or-later", which I think was the result of a request from the
> FSF to make it clearer whether the "or later" clause of the {A,L,}GPL
> family was allowed or excluded.
It was, yes. The current SPDX identifiers for those licenses are a
political compromise that I wouldn't want to revisit if I were SPDX.
> I would personally be in favour of (b) as our long-term direction, but
> for now the status quo is basically a variation of (a): keep using the
> Debian-specific names where they exist, but where there is no
> Debian-specific name for a license, the SPDX name is as good a name as
> any other.
Agreed on both counts.
Fedora is adopting SPDX wholesale, so while we were dubious at first
whether SPDX had staying power, it looks like it does and is slowly
becoming the standard in free software. In the long term, that's probably
the direction we want to go. In the short term, I don't think there's a
huge hurry; there are minor advantages to aligning with them, but SPDX
still has a ton of work to do to absorb all of the licenses in Fedora,
which will help us when we're ready to do a switch. (But I would
definitely use SPDX identifiers where there isn't a Debian standard to
follow, since it will make that switch easier.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1004522: debian-policy: Proposing new virtual package: wayland-session
Simon McVittie writes:
> GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
> /usr/{,local/}share/wayland-sessions/*.desktop and make them available
> as desktop sessions that users can choose, in addition to listing the
> X11 sessions that they traditionally did.
> At the moment, installing gdm3 pulls in either gnome-session (a minimal
> GNOME desktop), or some sort of X11 thing (usually a session manager,
> but sometimes a window manager or an xterm), but it should ideally be
> possible to install gdm3 as a login prompt from which to launch a
> non-GNOME Wayland session like weston or sway.
> I propose this entry for virtual-package-names-list.yaml:
> - name: wayland-session
> description: a Wayland desktop session
> (/usr/share/wayland-sessions/*.desktop)
I trust Simon to understand the issues here and nothing about this jumps
out as a problem, so seconded. This seems like an appropriate use of a
virtual package because this is a fairly broad-ranging interface that will
require coordination between separate packaging teams (such as the GNOME
and KDE teams).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#998165: debian-policy: document and allow Description in the source paragraph
Simon McVittie writes: > I believe the intention is to automate this pattern, which a lot of > packages with shared libraries are already using: > Source: dbus > Package: dbus > Description: simple interprocess messaging system (system message bus) > D-Bus is a message bus, used for sending messages between applications. > [the real Description goes into more detail here] > . > This package provides a fully-functional D-Bus system bus [etc.] [...] This is somewhat of an aside, but the order of those two paragraphs should really be reversed, under the maxim that the most important information about a package should go first due to possible truncation in the UI used to view package descriptions (and also in the human tendency to only read the first paragraph). In other words, rather than: > Package: libdbus-1-3 > Description: simple interprocess messaging system (library) > D-Bus is a message bus, used for sending messages between applications. > [the real Description goes into more detail here] > . > This package provides the runtime library for use by applications. I think we should prefer: Package: libdbus-1-3 Description: simple interprocess messaging system (library) The runtime D-Bus library for use by applications. . D-Bus is a message bus, used for sending messages between applications. [the real Description goes into more detail here] -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#998165: debian-policy: document and allow Description in the source paragraph
Nicholas D Steeves writes: > The following is only Informational level, but the existence of > Lintian's "duplicate-long-description" tag suggests that producing > duplicate bin:Descriptions in bin:libfoo and bin:foo packages is not > ideal, thus a straight copy from src:Description is not ideal. I'm not > sure what the best way to solve this is, but substvar looks like a good > solution. Alternatively, simply appending "\n\n$binary_pkg\n" to the > src:Description when generating the bin:pkg Descriptions would do the > trick. Maybe there's an even better way? What's wrong with duplicate descriptions? I think we need to answer that question first before deciding whether the Lintian tag is telling us anything meaningful. Policy has a fairly good description of the intention of the package description: https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions I think the additional caveat, and the primary place where I've seen packages duplicate the same long description, is that there are a bunch of packages in Debian that are essentially never installed directly by a systems administrator, and thus for which the package description doesn't matter a ton if there's nothing else to describe (like conflicts or dependencies). Library packages are a typical example; they're pulled in as dependencies. I personally tend to add a sentence to the top of the binary package description saying something like "Provides the shared libraries for foo" or "Provides architecture-independent support files used by foo" and then put the shared long description in the second paragraph, which wouldn't be flagged by Lintian. But I'm not sure the practice of putting "- shared library" in the synopsis and using the same long description is all that bad or something we should worry about discouraging. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#998165: debian-policy: document and allow Description in the source paragraph
Mattia Rizzolo writes: > |+When used in a source control file in the general paragraph (i.e., the > |+first one, for the source package), the text in this field is used to > |+describe the source package itself, and consequently all of the binary > |+packages built from itself. What if we just left off that paragraph entirely? I'm not sure it's adding anything. The new text would then read: In a source or binary control file, the ``Description`` field contains a description of the package, consisting of two parts, the synopsis or the short description, and the long description. If it's in a source control file, it's a description of the source package; if it's in a binary control file, it's a description of the binary package. That seems obvious, so I'm not sure we need to say it explicitly. That said, 5.6.13 currently technically doesn't document Description for a source package control file, only for source or binary control files or (later, with entirely different syntax) for *.changes files. Maybe that's the root of the problem. In that case, I think the paragraph we need is: The ``Description`` fields in source package control files are used to construct the ``Description`` fields for the source and binary control files when the package is built. Any ``Description`` field in the first paragraph of the source package control file becomes the description of the source package for the source binary control file. ``Description`` fields in subsequent paragraphs become the description of the corresponding binary packages. See deb-substvars(5) for some substitution variables that may be useful when writing binary package descriptions, such as ``source:Synopsis`` and ``source:Extended-Description``. BTW, I think "3.4 The description of the package" may also need some minor updates. At the least, "Every Debian package" should probably say "Every Debian binary package" since I don't think we're requiring source packages to have descriptions. It may also be worth adding a paragraph explaining that source packages may have descriptions as well, but are not required to. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1002626: debian-policy: building packages should not require to be root
Sean Whitton writes: > I said that the requirement is only advisory based on how there is no > requirement on packages expressed must/should/etc. in the description of > Rules-Requires-Root: no in Policy. The target of the advice would be > authors and maintainers of package builders. > However, I missed the use of "required" in the text, which means there > is in fact a Policy requirement not to fail to build as non-root when > this field value is declared, I think? > Sorry for causing some confusion here. Oh, no problem at all, and that makes sense. FWIW, I think Policy requirements may be the wrong way of thinking about this problem. If I try to compile a Perl module with GCC in debian/rules, I would be hard-pressed to name a specific Policy requirement that violates, but the package wouldn't build and that's a FTBFS bug. This feels more like that: the package metadata says to build it as non-root, which means that if it doesn't build as non-root, that's a FTBFS bug. Anyway, it all seems to be sorted out now, and I suspect the root problem was some benign misunderstanding of the root cause Vincent's bug report. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1002626: debian-policy: building packages should not require to be root
Guillem Jover writes: > But, the builder in this context is the program driving debian/rules and > not any external wrappers, in this case dpkg-buildpackage, which has > honored the field since it got implemented in 1.19.0. We drafted it as > "the builder" to allow for other potential drivers, because we are still > considering debian/rules the canonical entry point (even though I still > think we should ideally stop supporting calling it directly, and instead > should make dpkg-buildpackage the only supported interface). Oh, my apologies, I missed that detail. >> […] It looks like that's not the case, so I think this was just a >> bog-standard FTBFS, only a bit surprising because it was triggered by >> honoring Rules-Requires-Root, which I'm not sure the buildds do (yet). > The buildds have "honored" R³ since dpkg-buildpackage does. I had remembered (probably from some distant past) buildds always running builds as root, and just confused myself and probably other people. Sorry about that! I'm therefore confused why postfix didn't FTBFS on the buildds by failing to remove that read-only file. Clearly there must be some difference in the build environment for Daniel and Vincent or postfix would have always refused to build, but I'm not sure what that is. (In any case, I'm fairly convinced this isn't a Policy bug, although it sounds like the wording for R³ in Policy could be improved somewhat.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1002626: debian-policy: building packages should not require to be root
Vincent Lefevre writes: > On 2021-12-25 14:48:33 -0800, Russ Allbery wrote: >> Vincent Lefevre writes: >>> Here, the build via "debuild" is failing even when fakeroot is >>> available (installed on the machine). Note that Rules-Requires-Root >>> has been set to "no". IMHO, the policy should say that when >>> Rules-Requires-Root is set to "no", being root or using fakeroot >>> should not be required. >> It does already. >> no: Declares that neither root nor fakeroot is required. Package >> builders (e.g. dpkg-buildpackage) may choose to invoke any target in >> debian/rules with an unprivileged user. >> Am I missing something? > According to Sean, this is just advisory (and Scott Kitterman seemed > to assume that a build failure as non-root[*] was not a RC bug). I don't understand what "advisory" means here. This field controls the behavior of the package building software. If the package says that root isn't required, the package will be built without root. If root turns out to be required, the package will FTBFS. There's nothing "advisory" about having inaccurate package metadata that causes FTBFS, surely? Presumably the question is about the severity of the bug, but I don't think the severity question has anything to do with the Policy wording or would change if we worded Policy differently. The package says that you don't have to run it as root, so an autobuilder that knows about Rules-Requires-Root won't run the build as root, the build will fail, and that's a FTBFS bug, regardless of what Policy says. Presumably Lucas would report it as such if his builder supports Rules-Requires-Root. Reading the bug log, I'm not sure there's even any disagreement about that. What I see instead is that Scott was surprised that the file being removed was not writable and thought that was something that you had done in the local build system and that therefore wouldn't happen with other rebuild efforts. It looks like that's not the case, so I think this was just a bog-standard FTBFS, only a bit surprising because it was triggered by honoring Rules-Requires-Root, which I'm not sure the buildds do (yet). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1002626: debian-policy: building packages should not require to be root
Vincent Lefevre writes: > Here, the build via "debuild" is failing even when fakeroot is available > (installed on the machine). Note that Rules-Requires-Root has been set > to "no". IMHO, the policy should say that when Rules-Requires-Root is > set to "no", being root or using fakeroot should not be required. It does already. no: Declares that neither root nor fakeroot is required. Package builders (e.g. dpkg-buildpackage) may choose to invoke any target in debian/rules with an unprivileged user. Am I missing something? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Question on the use of "/nonexistent"
Jason Franklin writes: > I suppose a note in the documentation could clarify things for users who > may not be aware of these other usage scenarios. Yeah, that occurred to me after sending my message and indeed would be a great idea. That may be the right way to close this bug (with a documentation patch). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Question on the use of "/nonexistent"
Jason Franklin writes: > I am a developer who is new to making contributions to Debian. Most of > my work so far has been focused on making improvements to the "adduser" > package. Of course, bug triage is one of the first things on which I am > trying to show progress. > On the relevant BTS page, I came across this bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152195 > A summary of this bug is below... > # adduser --system --no-create-home foo > # getent passwd foo > foo:x:130:65534::/home/foo:/usr/sbin/nologin > As you can see, "/home/foo" is named as the new user's home directory, > but that directory is not created due to the "--no-create-home" option. > This was reported many years ago and was given the "wontfix" tag. I don't think this is a bug at all and should just be closed. I believe people are misunderstanding what --no-create-home means. The point of the --no-create-home option is that the administrator wants to handle the home directory creation themselves rather than have adduser do it. This is common when /home comes from a shared network file system, for example, where adduser will likely not have permissions to create the home directory. It can also come up in other situations, such as automounted home directories. The documentation says simply: --no-create-home Do not create the home directory, even if it doesn't exist. Passing --no-create-home therefore does not *change* the home directory, and should not change the home directory, since that would defeat its entire purpose. The home directory is still set the same as before, including any defaults. adduser just doesn't try to create it or check if it exists, because this should be handled external to adduser. If a user should have a nonexistent home directory, --home /nonexistent should be passed to adduser. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#992601: Allow non-64-bit packages to install to /usr/lib64/ again
Sean Whitton writes: > Seeking seconds: > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 83b71b1..131b450 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -48,8 +48,8 @@ Debian Policy. The following exceptions to the FHS apply: > libraries must not install these libraries to > ``/usr/lib/i386-linux-gnu``. [#]_ > -Packages must not install files in ``/usr/lib64`` or in a subdirectory > -of it. > +Packages for 64-bit architectures must not install files in > ``/usr/lib64`` > +or in a subdirectory of it. > The requirement for C and C++ headers files to be accessible through > the search path ``/usr/include/`` is amended, permitting files to be Seconded. Thanks, Sean. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Debian Policy 4.6.0.0 released
Sean Whitton writes: > On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote: >> This path is used by the multilib 64-bit toolchain on 32-bit >> architectures, for instance libc6-amd64:i386, or a few essential >> libraries like ncurses. >> >> What kind of fix do you expect on the packages? Is it finally the time >> to get rid of multilib and use pure multiarch instead? > We did not intend to make any packages buggy with this change. It was > thought to be just a clarification. > Russ, perhaps we should revert this? Yes, that was a subtlety that I had completely failed to grasp and didn't realize this was way the rule was worded the way it was. Sorry for that mistake; we should revert it. If we separately want to drop this in favor of pure multiarch, that's great and we can always reflect that later, but we shouldn't make that change based on my mistake in Policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#986320: Stronger advice on when to use native packages
Sam Hartman writes: > I'd propose the following way forward: > 1) Capture the discussion thread we had during my DPL term and the > things to think about that were brought up in the native packages part > of that discussion. > I'm not sure policy is the right place for those; I think some of those > might better belong in a wiki page or dev ref. > 2) Figure out what the work flow gaps are that cause people to find > native packages easier to deal with. > I suspect we'll find that something in our git workflows is not great > especially for closely tracking upstream git and especially when > upstream itself doesn't make releases. > 3) Fix these work flow gaps. > 4) Then add advice to policy. Thank you for this perspective! I had entirely forgotten about that. Realistically, I probably won't be able to drive this myself (at least soon), since I want to try to dig through the Policy backlog for places where we're blocking progress (which I don't think is true here). But even if we don't tackle this soon, I think this is a great statement of the issues. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Sam Hartman writes: >>>>>> "Russ" == Russ Allbery writes: > Russ> Here is an updated diff that documents the most > Russ> well-understood version conventions in the Debian archive. > Russ> More could certainly be added; this is just a first start that > Russ> addresses this specific bug. > Russ> This revised patch is less aggressive about defining native > Russ> packages to only mean packages with no existence external to > Russ> Debian. I also found that we never define upstream, which > Russ> seems like a critical concept, so I added a definition to the > Russ> Definitions section. > second. Hi Sam, Thanks for the review! There's now a newer version of this diff adjusted for a flaw that Simon pointed out. It's sufficiently different from the original diff that I don't want to count seconds for the original as seconds for it. It's at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280 -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#986320: Stronger advice on when to use native packages
David Bremner writes: > Russ Allbery writes: >> Currently, Debian Policy is silent on when it's appropriate to use a >> native package, but there may be a project consensus aganist using >> native packages when the software has an existence outside of Debian. > Personally I don't think Debian policy should be concerned with what > happens outside Debian. As long as a given process serves the users and > contributors of/to Debian well, that seems sufficient to me. To be clear, my understanding of the advocacy of using non-native packages is primarily about their impact on *Debian* workflows (being able to base multiple packages on the same tarball, not introducing confusion between upstream version numbers and Debian version numbers and thus making it easier for other people in Debian to track the package to an upstream version, triggering various package checks that ignore native packages but care about non-native packages such as uscan, etc.). > I understand that others disagree, particularly on how much we should > consider the needs of derivative distributions. This is a good additional point for discussion, though, since I vaguely recall that using native packages had some oddities for derivative distributions, which is a significant Debian user use case. >> Even if that consensus does not exist, there is probably consensus that >> native packages are a poor match for large packages (because of the >> inefficiency of making small updates to the packaging of native >> packages), and there may be other cases where we can give stronger >> guidance. > That seems more like something that could be documented in devref as a > best practice, rather than something needing normative language. Yes, that's a good point; it's possible that some or all of this belongs in devref rather than Policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#986320: Stronger advice on when to use native packages
Package: debian-policy Version: 4.5.1.0 Severity: wishlist Currently, Debian Policy is silent on when it's appropriate to use a native package, but there may be a project consensus aganist using native packages when the software has an existence outside of Debian. Even if that consensus does not exist, there is probably consensus that native packages are a poor match for large packages (because of the inefficiency of making small updates to the packaging of native packages), and there may be other cases where we can give stronger guidance. Probe the project consensus here and see if Policy should say something stronger. (See #542288 for some of this discussion.) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /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 3.4.3-2 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#875531: "editor +42 filename" -- accept or reject?
Adam Borowski writes: > Now that you folks are dealing with the "editor" virtual package, and, > what interests me here, the alternative for /usr/bin/editor -- could you > please process this proposal as well, and either accept or close it? > My point is that, all but one (e3) current alternatives allow > positioning the cursor on a given line, and various users take > inconsistent approach as to when this feature can be used. Thank you for doing the research to confirm this is supported by all the editor alternatives! That makes this fairly easy. Attached is a proposed diff. This is on top of the diff for #682347; it's separable, but I'd prefer to get that seconded and merged first. Note that, based on your research, this will make e3 RC-buggy. (Obviously this wouldn't be RC for this upcoming release.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst index 27abebd..d58e297 100644 --- a/policy/ch-customized-programs.rst +++ b/policy/ch-customized-programs.rst @@ -93,6 +93,14 @@ alternative should have a slave alternative for ``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual page. +Packages that register as an alternative for ``/usr/bin/editor`` must +support the following features: + +- When invoked as ``editor ``, they open for + editing. +- When invoked as ``editor +N ``, they open for + editing and position the cursor or equivalent at line ``N`` of the file. + Packages that register as an alternative for ``/usr/bin/editor`` should also provide the virtual package ``editor`` by including it in the ``Provides`` control field. The package providing the current default
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Holger Levsen writes: > I'm not sure if in this regard I would have liked the previous version > better, as the paragraph about native packages is the only one which I > would like to see extended to explain that it has been observed that > packages we thought were native to Debian were not really native to > Debian at all and require modifications in Debian downstream > distributions, which are harder to do when the packages are native (eg > modified orig.tar's despite no upstream changes). This is generally my opinion as well, but I know there are other folks who disagree, and I'm therefore not sure whether this has consensus. (Native packages are a lot simpler.) I decided to take the easy way out and note that this bug was originally about documenting NMU and stable upload version conventions, so setting policy for when people should use native packages is a bit out of scope. I'll therefore propose that we move the discussion of whether to give stronger advice on when to use native packages to a separate bug. Once this is merged, there will be some text in Policy defining native packages, so it will be easier to work on that. Sound good? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Simon McVittie writes: > The other way is to repackage the new upstream release from first > principles, either because it's a new release from an upstream branch > that's older than the one in testing/unstable (like src:flatpak in > Debian 10), or because testing/unstable already has packaging changes > that aren't suitable for stable (like src:dbus in Debian 10). In this > case it would be misleading to use a version number like > flatpak_1.2.5-1~deb10u1 (because 1.2.5-1 never existed) or > dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did exist, but the version of > dbus in stable was not based on it, and does not have the downstream > changes from that version). Instead, the convention that has emerged is > to use 0+deb10u1, by analogy with the convention that an NMU introducing > a new upstream release has revision number 0.1. Ah, thanks for this. I wasn't aware this convention existed. Here's a new draft, which is unfortunately quite a bit longer because it's hard to make this clear. I also added the +really convention explicitly, since it's mentioned immediately above, and noted that the stable update and backport conventions can, in rare circumstances, stack. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index a21a510..2fd6868 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -582,20 +582,17 @@ The three components here are: alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop, tilde) and is compared in the same way as the ``upstream_version`` is. -It is optional; if it isn't present then the ``upstream_version`` -may not contain a hyphen. This format represents the case where a -piece of software was written specifically to be a Debian package, -where the Debian package source must always be identical to the -pristine source and therefore no revision indication is required. +It is conventional to restart the ``debian_revision`` at ``1`` each +time the ``upstream_version`` is increased. -It is conventional to restart the ``debian_revision`` at ``1`` -each time the ``upstream_version`` is increased. +The package management system will break the version number apart at +the last hyphen in the string (if there is one) to determine the +``upstream_version`` and ``debian_revision``. The absence of a +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``. -The package management system will break the version number apart -at the last hyphen in the string (if there is one) to determine -the ``upstream_version`` and ``debian_revision``. The absence of a -``debian_revision`` is equivalent to a ``debian_revision`` of -``0``. +Presence of the ``debian_revision`` part indicates this package is a +non-native package (see :ref:`s-source-packages`). Absence indicates +the package is a native package. When comparing two version numbers, first the epoch of each are compared, then the ``upstream_version`` if epoch is equal, and then @@ -625,6 +622,8 @@ These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. +.. _s-avoid-epochs: + Epochs should be used sparingly ^^^ @@ -639,13 +638,132 @@ Epochs should not be used when a package needs to be rolled back. In that case, use the ``+really`` convention: for example, if you uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2, call your reverting upload something like ``2.3+really2.2-1``. -Eventually, when we upload upstream 2.4, the +really part can go away. +Eventually, when we upload upstream 2.4, the ``+really`` part can go away. Epochs are also not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly orderings. [#]_ +Special version conventions +^^^ + +The following special version numbering conventions are used in the Debian +archive: + +- The absence of ``debian_revision``, and therefore of a hyphen in the + version number, indicates that the package is native. + +- The presence of ``+really`` in the ``upstream_version`` component + indicates that a newer upstream version has been rolled back to an older + upstream version. The part of the ``upstream_version`` component + following ``+really`` is the true upstream version. See + :ref:`s-avoid-epochs` for an example of when this is used. + +Non-maintainer uploads: + +- ``debian_revision`` components ending in ``.`` (period) followed by a + number indicate this version of the non-native package was uploaded by + someone other than the maintainer (an NMU or non-maintainer upload). + This is use
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Here is an updated diff that documents the most well-understood version conventions in the Debian archive. More could certainly be added; this is just a first start that addresses this specific bug. This revised patch is less aggressive about defining native packages to only mean packages with no existence external to Debian. I also found that we never define upstream, which seems like a critical concept, so I added a definition to the Definitions section. I've also reviewed the places where the Developer's Reference talks about similar issues and I believe this is consistent with it. I think this change is ready for seconds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index a21a510..cd7daaa 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -582,20 +582,17 @@ The three components here are: alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop, tilde) and is compared in the same way as the ``upstream_version`` is. -It is optional; if it isn't present then the ``upstream_version`` -may not contain a hyphen. This format represents the case where a -piece of software was written specifically to be a Debian package, -where the Debian package source must always be identical to the -pristine source and therefore no revision indication is required. +It is conventional to restart the ``debian_revision`` at ``1`` each +time the ``upstream_version`` is increased. -It is conventional to restart the ``debian_revision`` at ``1`` -each time the ``upstream_version`` is increased. +The package management system will break the version number apart at +the last hyphen in the string (if there is one) to determine the +``upstream_version`` and ``debian_revision``. The absence of a +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``. -The package management system will break the version number apart -at the last hyphen in the string (if there is one) to determine -the ``upstream_version`` and ``debian_revision``. The absence of a -``debian_revision`` is equivalent to a ``debian_revision`` of -``0``. +Presence of the ``debian_revision`` part indicates this package is a +non-native package (see :ref:`s-source-packages`). Absence indicates +the package is a native package. When comparing two version numbers, first the epoch of each are compared, then the ``upstream_version`` if epoch is equal, and then @@ -646,6 +643,83 @@ numbers containing strings of letters which the package management system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly orderings. [#]_ +Special version conventions +^^^ + +The following special version numbering conventions are used in the Debian +archive: + +- The absence of ``debian_revision``, and therefore of a hyphen in the + version number, indicates that the package is native. + +- ``debian_revision`` components ending in ``.`` (period) followed by a + number indicate this version of the non-native package was uploaded by + someone other than the maintainer (an NMU or non-maintainer upload). + This is used for a source package upload; for uploads of only binary + packages without source changes, see the binary NMU convention below. + +- ``upstream_version`` components in native packages ending in ``+nmu`` + followed by a number indicate an NMU of a native package. As with the + convention for non-native packages, this is used for a source package + upload, not for uploads of only binary packages without source changes. + +- ``upstream_version`` components in native packages or + ``debian_revision`` components in non-native packages ending in ``+b`` + followed by a number indicate a binary NMU: an upload of a binary + package without any source changes and hence without any corresponding + source package upload or version change. + +- ``upstream_version`` components in native packages or + ``debian_revision`` components in non-native packages ending in + ``+debNuX`` indicate a stable update. This is a version of the package + uploaded directly to a stable release, and the version is chosen to sort + before any later version of the package uploaded to Debian's unstable + distribution. ``N`` is the major version number of the Debian stable + release to which the package was uploaded, and ``X`` is a number, + starting at 1, that is increased for each stable upload of this package. + + For example, suppose Debian 10 released with a package with version + ``1.4-5``. If that package later receives a stable update in Debian 10, + the first update would have the version ``1.4-5+deb10u1``. A subsequent + update would have version ``1.4-5+deb10u2``. These numbers are designed + to sort earlier than ``1.4-6``, the version number that would be used + for th
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Paul Hardy writes: > I recently formatted the Unicode Data license for the d/copyright file > of a Debian package that I created. I thought I would offer it to > Debian if you are interested. You probably do not want the Copyright > stanza, and you might not want the Comment stanza, but I erred on the > side of too much rather than too little. > Unicode data files are used in a number of free software packages, such > as linux-libc-dev and the Linux kernel itself. Use of Unicode data in > software is likely to continue growing over time. Thus you might find > this useful. Hi Paul, It looks like you included the entire statement from the web site, which I think is intended to cover the whole web site. As near as I can tell, the files that Debian is packaging are the ones referenced by this stanza: 4. Further specifications of rights and restrictions pertaining to the use of the particular set of data files known as the "Unicode Character Database" can be found in the License. and therefore appear to only be covered by this license instead: https://www.unicode.org/license.html The full license that you formatted includes a bunch of other clauses like choice of venue and unilateral license changes that I don't think are intended to cover the things that we're packaging. I think we should therefore consider incorporating only the above text instead? Scott Kitterman writes: > According to my wrangling of codesearch.debian.net, unicode.org gets > mentioned in over 1,000 packages and it's mostly about this data. I > think that's enough to merit inclusion in common-licenses. Could you provide more detail on your search? I searched for: path:debian/copyright DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC and only found 26 packages. I'm not sure that's enough to warrant inclusion in common-licenses. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#682347: resurrect editor virtual package name
Russ Allbery writes: > 2. Document editor and recommend everyone implement it properly. Since >we're going to allow packages to depend on editor, I think providing >it would need to be a should, so that's going to be a lot of buggy >(but not RC-buggy) editor packages. But it would get us to a clean >dependency system. (I will leave it to someone else to tackle this >for pager if someone really wants to.) When I let the ball drop on this three years ago, there was a consensus that this option was the way to go. Picking this up again, here is a proposed Policy change to document the editor and default-editor virtual packages. Note that this would make quite a few packages buggy (but not RC-buggy) since they don't Provide: editor although they participate in the /usr/bin/editor alternative. This was considered reasonable since it would be cleaning up the dependency structure and the bug is fairly minor and can be dealt with when those maintainers have a chance. I'm looking for seconds for this diff. It documents the status quo for /usr/bin/pager; if we want to make a similar cleanup there, we can do that as a separate bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst index 747df56..27abebd 100644 --- a/policy/ch-customized-programs.rst +++ b/policy/ch-customized-programs.rst @@ -93,21 +93,30 @@ alternative should have a slave alternative for ``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual page. -If it is very hard to adapt a program to make use of the EDITOR or PAGER -variables, that program may be configured to use -``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the -editor or pager program respectively. These are two scripts provided in -the sensible-utils package that check the EDITOR and PAGER variables and +Packages that register as an alternative for ``/usr/bin/editor`` should +also provide the virtual package ``editor`` by including it in the +``Provides`` control field. The package providing the current default +editor for the Debian base system, and only that package, should also +provide the ``default-editor`` virtual package. Packages that call +``editor`` directly (not via ``sensible-editor`` or the EDITOR environment +variable) should depend on ``default-editor | editor``. + +Programs may assume that ``/usr/bin/pager`` is available as a fallback +without adding an explicit package dependency. There is no ``pager`` +virtual package. + +If it is difficult to adapt a program to use the EDITOR or PAGER +variables, that program may instead be configured to use +``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the editor +or pager program respectively. These are scripts provided by the +``sensible-utils`` package that check the EDITOR and PAGER variables and launch the appropriate program, and fall back to ``/usr/bin/editor`` and -``/usr/bin/pager`` if the variable is not set. +``/usr/bin/pager`` if the variable is not set. Packages using these +scripts should declare an appropriate dependency on ``sensible-utils``. A program may also use the VISUAL environment variable to determine the user's choice of editor. If it exists, it should take precedence over -EDITOR. This is in fact what ``/usr/bin/sensible-editor`` does. - -It is not required for a package to depend on ``editor`` and ``pager``, -nor is it required for a package to provide such virtual -packages. [#]_ +EDITOR. This is also what ``/usr/bin/sensible-editor`` does. .. _s-web-appl: @@ -573,10 +582,6 @@ installed in ``/usr/share/man/man6``. portion is handled internally by the package system based on the os and cpu. -.. [#] - The Debian base system already provides an editor and a pager - program. - .. [#] If it is not possible to establish both locks, the system shouldn't wait for the second lock to be established, but remove the first diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml index 2a9857a..6c0b59e 100644 --- a/virtual-package-names-list.yaml +++ b/virtual-package-names-list.yaml @@ -100,6 +100,14 @@ virtualPackages: # System + - name: default-editor + description: default base system /usr/bin/editor + alternatives: + - /usr/bin/editor + - name: editor + description: suitable /usr/bin/editor + alternatives: + - /usr/bin/editor - name: flexmem description: anything that can access flexible memory via the OBEX Protocol - name: foomatic-data @@ -457,3 +465,7 @@ virtualPackages: # Added default-dbus-session-bus # 15 Feb 2019 Added logind # Added default-logind +# +# Russ Allbery: +# 01 Apr 2021 Added editor +# Added default-editor
Bug#932696: Please document Haskell team style Vcs-Git sytax
Ian Jackson writes: > Package: debian-policy > Version: 4.4.0.1 > Many packages' .dscs contain something like this: > Source: bustle > Version: 0.7.4-1 > Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle] > The semantics do not appearr to be documented in policy. Reminder that this proposed patch needs one more second to be merged into the next release of Policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index a21a510..2a2e364 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -972,11 +972,33 @@ repository where the Debian source package is developed. - Mtn (Monotone) - Svn (Subversion) -In the case of Git and Mercurial, the value consists of a URL, -optionally followed by the word ``-b`` and the name of a branch in -the indicated repository, following the syntax of the ``git clone`` -or ``hg clone`` command. If no branch is specified, the packaging -should be on the default branch. +In the case of Git, the value must have the following syntax:: + + [ " -b " ] [ " [" "]" ] + +where the portions enclosed in brackets are optional and the portions +enclosed in double quotes are literal strings. indicates +the repository. If the stanza is present, it names a +branch in the indicated repository. If no branch is specified, the +packaging should be on the default branch. If the stanza +is present, it specifies the relative path to the top of the packaging +tree (the parent directory of the ``debian`` directory). If no path +is specified, it defaults to ``.`` (the top level of the indicated +repository and branch). + +For example:: + +Vcs-Git: https://example.org/repo -b debian [p/package] + +indicates a subdirectory named ``p/package`` in the ``debian`` branch +of the repository at ``https://example.org/repo``. + +In the case of Mercurial, the value must have the following syntax:: + + [ " -b " ] + +This is interpreted the same way as the Git syntax except a path +within the repository is not supported. A package control file must not have more than one ``Vcs-`` field. If the package is maintained in multiple version control
Bug#944920: Revise terminology used to specify requirements
Russ Allbery writes:
> In attempting to revise recent GRs to use the same terminology as
> Policy, I got frustrated again by the lack of precision of our current
> language. This is an attempt to make a minor improvement. It doesn't
> go all the way to using all-caps terms the way that RFC 2119 does; I
> think that might be an improvement, but it was a larger change than I
> wanted to tackle.
It's been over a year since the last activity on this bug so although
there were enough seconds for a revised form of this patch, I'm reposting
it to remind people where the discussion was and as a quick double-check
that I didn't mess up the rebase.
This includes relaxing the debian/missing-sources wording back to optional
again, although I kept some rewording of that paragraph to hopefully make
it a bit clearer.
Proposed debian/changelog entry:
* Policy: Add new encouraged keyword, make keywords consistent
Wording: Russ Allbery
Seconded: Sam Hartman
Seconded: Sean Whitton
Closes: #944920
* Clarify that no package may install files in /usr/lib64. The previous
wording implied this restriction only applied to 64-bit packages.
* Reserve the /etc/rcn.d directories for the init-system-helpers package
rather than the sysvinit package, reflecting a change already made in
the archive.
Attached is a regular unified diff since I think that's marginally easier
to read (although I'm very used to unified diffs). For folks who want a
word diff instead, clone https://salsa.debian.org/dbnpolicy/policy.git and
run git diff --word-diff next..bug944920-rra
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/debian/changelog b/debian/changelog
index fe13e5a..b4d81f1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
debian-policy (4.5.2.0) UNRELEASED; urgency=medium
+ [ Sean Whitton ]
* Policy: Allow manpages to be included in the dependencies of packages
Wording: Helmut Grohne
Seconded: Russ Allbery
@@ -7,6 +8,18 @@ debian-policy (4.5.2.0) UNRELEASED; urgency=medium
Seconded: Sean Whitton
Closes: #983657
+ [ Russ Allbery ]
+ * Policy: Add new encouraged keyword, make keywords consistent
+ Wording: Russ Allbery
+Seconded: Sam Hartman
+Seconded: Sean Whitton
+Closes: #944920
+ * Clarify that no package may install files in /usr/lib64. The previous
+wording implied this restriction only applied to 64-bit packages.
+ * Reserve the /etc/rcn.d directories for the init-system-helpers package
+rather than the sysvinit package, reflecting a change already made in
+the archive.
+
-- Sean Whitton Sun, 28 Feb 2021 14:25:28 -0700
debian-policy (4.5.1.0) unstable; urgency=medium
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 5fbc0a3..ab04261 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -348,8 +348,8 @@ management tools.
the user doesn't select anything else. It doesn't include many large
applications.
-No two packages that both have a priority of ``standard`` or higher
-may conflict with each other.
+Two packages that both have a priority of ``standard`` or higher must
+not conflict with each other.
``optional``
This is the default priority for the majority of the archive. Unless
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 784bca3..937d0d9 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts must provide
the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
All packages which supply an instance of a common command name (or, in
-general, filename) should generally use ``update-alternatives``, so that
-they may be installed together. If ``update-alternatives`` is not used,
+general, filename) should generally use ``update-alternatives`` so that
+they can be installed together. If ``update-alternatives`` is not used,
then each package must use ``Conflicts`` to ensure that other packages
are removed. (In this case, it may be appropriate to specify a conflict
against earlier versions of something that previously did not use
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..fdb1b51 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, architectures,
files or anything else) or version numbers, or between the characters of
multi-character version relationships.
-The presence and purpose of a field, and the syntax of its value may
+The presence and purpose of a field, and the syntax of its value, may
differ between types of control files.
Field names are not case-sensitive, but it is usual to capitalize the
@@ -571,19 +571,19 @@ The three components here are:
respect to the ``upstream_vers
Bug#983657: debian-policy: weaken manual page requirement
Helmut Grohne writes: > I call for seconds on: > --- a/policy/ch-docs.rst > +++ b/policy/ch-docs.rst > @@ -12,9 +12,9 @@ > "cat page". > > Each program, utility, and function should have an associated manual > -page included in the same package. It is suggested that all > -configuration files also have a manual page included as well. Manual > -pages for protocols and other auxiliary things are optional. > +page included in the same package or a dependency. It is suggested that > +all configuration files also have a manual page included as well. > +Manual pages for protocols and other auxiliary things are optional. > > If no manual page is available, this is considered as a bug and should > be reported to the Debian Bug Tracking System (the maintainer of the Seconded. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975250: clarify gathering together of copyright information
Guillem Jover writes: > Personally I see a big distinction between someone doing it for their > own copyright claims, and doing that for someone else's. Yeah, this is where I'm at too. It feels weird, and I'm not sure it's technically compliant with the license requirement to preserve the copyright notice for those licenses that have it. That said, I tend to be hyper-conservative and nit-picky about things like this, accurately representing copyright years isn't in my top thousand things I want people to work on in Debian, and I'm highly dubious that it will ever matter or anyone will ever care. So I'm very open to being told I'm being much too cautious. > AFAIUI when and what you have done before publication does not count > when it comes to copyright, only the publication date does. Yes, this is also my understanding, with the caveat that I only have read the US law in any detail and I don't know to what extent it varies. (I know Berne mostly standardizes copyright, but mostly isn't entirely and there are countries with fairly significant differences, such as moral rights. I have no idea how universal the exact semantics of copyright notices are under Berne.) Here's the circular from the US Copyright Office on notices, for whatever it's worth: https://www.copyright.gov/circs/circ03.pdf -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975250: clarify gathering together of copyright information
Sam Hartman writes: > I appreciate that the FSF cares about old years and things going into > public domain. I think that we should value being able to coalesce > years more than we value that pedantry. I think the FSF has adequately > explained the legal rationale for their view, I think their legal > reasoning is sound (so we can rely on it), and I think it doesn't apply > to our needs (so we can do something else). > I don't think we should go so far as to only list the most recent year, > but I do think we should collapse things down to a range in > debian/copyright. > I always assumed from the current wording we could do so and it's a > significant surprise to me that you are arguing we cannot. I personally don't particularly care, so if that's the consensus, I'm happy to go with that. Perhaps I'm being too pedantic. For whatever it's worth, I've never assumed we can coalesce years in a way that drops gaps, and never have done so myself, so it's obvious that we should write something down since two people who have both worked in Debian for a very long time had different understandings of what was allowed. :) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975250: clarify gathering together of copyright information
Marc Haber writes: > On Fri, Nov 20, 2020 at 01:58:51PM -0700, Sean Whitton wrote: >> On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote: >> > +Copyright field. It is ok to have years >> > +covered that are not listed in the original notices. >> I don't think we can assume it is okay to do this. You can combine >> 2009--2015 and 2020 into just 2009--2015, but I don't think we should >> encourage combining 2009--2011 and 2013 into 2009--2013. > That is what I assumed from the GNU wording quoted by Russ. The wording was used by upstream so the implication is that upstream is asserting copyright changes in each of those years. If we broaden that range, we're effectively adding copyright claims of additional years that aren't necessarily true. I have a hard time imagining that it would ever matter, but pedantically one cannot say 2009-2013 if no copyrightable changes happened in 2012. > What is the relevance of the years in leftpondian copyright law anyway? > Over here, copyright expires a certain time after the copyright holder's > death. In reality, this only matters because we have licenses that say it matters. For example, the BSD license saying: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. We're already arguably not *quite* following that rule by allowing coalescing of notices. I think that's fine because (at least in US law) the copyright notice is soemthing with a legal definition and the coalesced form is legally equivalent, so we're preserving the notice in the way that matters. But in order to rely on that argument, it feels like we should keep the notice legally equivalent, which would mean not adding years. The years are an annoying bit of pedantry. The short version is that US copyright law requires a year in the notice, and that year is supposed to represent a year in which a copyrightable change was "published." The FSF a long time back got legal counsel here and published guidance in the GNU Maintainer Guidelines, and since I've never wanted to reproduce that work, I tend to just follow them. They say: To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you’re using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track of which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. Don’t delete old year numbers, though; they are significant since they indicate when older versions might theoretically go into the public domain, if the movie companies don’t continue buying laws to further extend copyright. If you copy a file into the package from some other program, keep the copyright years that come with the file. You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a README file about this usage. Is this more pedantic than is necessary to comply with the law? Probably, plus copyright notices only matter in the law for damage claims and it's really hard to imagine a scenario in which any of this will matter. Do upstreams in general pay attention to this and have correct notices? Almost certainly not. But it's one of those topics where if one asks, this is the answer that people have gotten, even though it's kind of silly. Therefore, where I personally land is that we should try to make the Policy guidance correct (but as simple as possible), and then we should not care if people don't exactly follow it because in truth it's not going to matter. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#975250: clarify gathering together of copyright information
Marc Haber writes: > But what if file A says > | Copyright 2008 John Smith > | Copyright 2005-2015 Angela Watts > and file B has: > | Copyright 2010 Angela Watts > Can this be gathered together to: > | Copyright 2008 John Smith > | Copyright 2005-2015 Angela Watts I'm fairly sure the answer in practice is yes. I've been uploading packages like this for some time without any issues, and I would be very surprised if ftp-master would object. I think we may need to be a bit more verbose in explaining how copyright statements can be coalesced to make this clear. Some GNU projects use wording like this: For any copyright year range specified as - in this file, the range specifies every single year in that closed interval. and maybe we should import something like that into our specification as well as say explicitly that you're allowed to coalesce copyright statements from multiple files into a single copyright notice as long as all of the listed authors and years are covered. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#968226: Build-Depends-If-Available
Wouter Verhelst writes: > -policy: this is a question that has come up before > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another > example that springs to mind, but I'm pretty sure there are more), so I > think we should document in Policy that a) buildd only looks at the > first dependency in alternative build-dependencies, and b) why this is > the case. Policy already says: While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit the use of alternative dependencies, these are not normally used by the Debian autobuilders. To avoid inconsistency between repeated builds of a package, the autobuilders will default to selecting the first alternative, after reducing any architecture-specific restrictions for the build architecture in question. While this may limit the usefulness of alternatives in a single release, they can still be used to provide flexibility in building the same package across multiple distributions or releases, where a particular dependency is met by differently named packages. in 7.1. However, it's hidden in a footnote. Perhaps we should make it more prominant (and make it clear that it's normative), and tweak the wording. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable
Guillem Jover writes: > On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote: >> I assume this is in support of systems, containers, or jails where UID >> 0 may not have CAP_FOWNER? > If that's the reason, it certainly was not clear from the original > report. :) It seems like the context in which this change would be meaningful. That said, in the situations where I'm dropping capabilities, I would also generally remount file systems like /usr read-only (systemd's ProtectSystem, for example), so I'm having some trouble generating a scenario in which the file permission changes matter. I think a concrete use case would be useful for analysis. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable
Ansgar writes: > 10.9 Permissions and owners currently says > | Files should be owned by root:root, and made writable only by the > | owner and universally readable (and executable, if appropriate), > | that is mode 644 or 755." > However most files shouldn't be modified as modifications will just be > lost (e.g. everything installed by the package manager that isn't > handled as a conffile). It also gives more permissions than the minimum > needed. > I think static files should not be writable instead, so every file under > /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is not a > conffile) should have 444 (or 555). I assume this is in support of systems, containers, or jails where UID 0 may not have CAP_FOWNER? The basic argument makes sense to me, but this is the sort of change where we'll need to figure out a transition strategy coordinated across multiple packages, since this behavior is encoded in a lot of places. Maybe it would make sense for Guillem to weigh in first and indicate whether this would be a problem on the dpkg side and if he sees any concerns. Copying debian-dpkg@lists for that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Thorsten Glaser writes: > Ian Jackson dixit: >> The problem is that `3.0 (quilt)' has both advantages (eg that >> `nativeness' is declared explicitly) and disadvantages (patches stored > Not necessarily: > | $ cat rs/debian/source/local-options > |single-debian-patch > | $ cat rs/debian/source/local-patch-header > |Please review changes against upstream code using SCM, > |see the Vcs-* tags in debian/control for its location. > | > (empty line at the end) > This allows working with 3.0 (quilt) packages precisely the same way > (well plus a “git clean -dfx” after building) than with 1.0 packages. local-options means that the maintainer sees a very different view of the package than any other consumer on the package via the archive. Not only is this philosophically a bit weird, it also breaks tools that try to keep the repository and maintainer view consistent (such as dgit). I suspect it is therefore not the solution Ian is looking for. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#961294: Allow derivatives to define parent project fields
Simon Quigley writes: > I recently had a discussion in a Lintian merge request[1] where I > submitted code solidifying existing behavior in the Ubuntu Desktop and > Lubuntu teams. As I stated there, it is common practice in those teams > (and I am sure it exists in others as well) to specify a > `XS-Debian-Vcs-Browser` and/or `XS-Debian-Vcs-Git` field to point to > Salsa. > The rationale for this is to allow packaging changes to flow back > upstream to Debian when Ubuntu's packaging repository is in a different > location (when Ubuntu has a permanent downstream delta but continues to > rebase that delta on top of Debian's changes). > I would like to solidify this existing practice by modifying Debian > Policy, amending 5.6.26 to allow usage of -Vcs-Browser and > -Vcs-. I'm not sure I understand why you want to make this change to Debian Policy. Isn't this a matter for Ubuntu policy? The new fields wouldn't be in the package in Debian (because they wouldn't be meaningful there). > I would also like to use this as an opportunity to deprecate > `Original-Maintainer` in favor of `Debian-Maintainer` and allow for > `Debian-Uploaders` as well. Similarly this seems to be entirely a question for Ubuntu (and Lintian, of course). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944920: Revise terminology used to specify requirements
Sean Whitton writes: > One issue with using uppercased words is that people might think the > words have the same meaning as they do in RFCs, which they don't. > Your idea of marking keywords in bold wouldn't have this problem, and > maybe it would actually make it /easier/ to write patches because you > can see more clearly which of your words mean what. It does have the drawback of being either less obvious or a bit noisy in the text output format, though, which I suspect is reasonably heavily used. I'm not sure our definitions are that far off from the RFC terms. We're not defining a protocol, so it's inherently a little different, but there are some clear equivalents. And it would avoid reinventing a new typographic convention. A long time ago, Manoj proposed a deeper, more comprehensive fix: stop writing Policy as English prose and instead explicitly state normative requirements in some sort of numbered, clear fashion, and then add a prose informative explanation if warranted. But I'm a bit dubious of that. Not only would it be a ton of work, but the more formal phrasing will require repeating ourself a lot more. Personally, I think I'm leaning mildly towards the all-caps keywords because of familiarity and compatibility with a pure text format, although I could be convinced otherwise. I do think making this change is a good idea. > Thinking more, I believe that the issue you're raising here is separate > from what Russ is trying to achieve in this bug. The problem you're > identifying here already exists in Policy, before Russ's change is > applied. So maybe we should discuss it separately. Yes, I'm behind but that was the thing I wanted to say: I'd like to merge this change (I haven't looked at more recent reviews, since I've been distracted with work, so I don't know off-hand if it's ready for merging otherwise) and then tackle this issue separately. But I do think it's time to tackle it. >> BTW I guess the instances of «might» and «shall» need to be converted, >> or added to the keyword list? What about «may not», or «can», «can't», >> «cannot» and «could»? And I'm probably missing other words. :) > I don't think we need to convert words that don't explicitly appear in > the keywords list -- "may not" would inherit its meaning from "may" > being a keyword, wouldn't it? I think that if the word doesn't appear in the keyword list, it shouldn't have any normative meaning. I have intentionally used the words can and cannot in Policy text precisely because they don't have normative meaning and don't state Policy requirements. For example, in: If punctuation is desired between the date components, remember that hyphen (``-``) cannot be used in native package versions. the "cannot" is not a normative Policy requirement, just a description of a logical consequence of a definition stated earlier. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: RFC: No new Essential packages?
Ansgar writes: > Is the current wording in Policy not sufficient? In 3.8 Essential > packages it states "this flag must not be used unless absolutely > necessary" and later "You must not tag any packages essential before > this has been discussed on the debian-devel mailing list and a consensus > about doing that has been reached". I think Josh is arguing that ideally we'd slowly move towards declaring dependencies on essential packages explicitly, so we should indicate that in Policy and, as a first step, say that we're not adding any entirely new functionality to the essential set if we can help it and instead asking people to just declare explicit dependencies. I've never liked the rule that you don't have to declare dependencies on essential packages and would love to phase it out as much as possible (I think even intermediate movement in that direction would be useful), but I'd like Guillem to weigh in from a dpkg perspective to indicate whether this makes sense to him and whether I'm missing something. (Also, that said, having every package that contains a shell script declare a dependency on sh | dash and every package that uses a common shell utility declare a dependency on coreutils, despite being a nice way to remove some special cases and make the dependency structure more explicit, may be a bit too tedious to want to endure.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong
Simon McVittie writes: > If a package has a single system service with a systemd service unit, > and the system service's name does not match the package's name, current > Policy implies that this is probably a (non-RC) bug. > I think that's too strong. In particular, because the name of the service > unit is part of the "API surface" of the system service, aligning the > name of the service unit with the name used by upstream is usually > more important than aligning it with the name of the Debian package, > unless the name used by upstream results in conflicts or is otherwise > poorly-chosen. This is analogous to the names of executables in the PATH > and the SONAMEs of libraries, both of which we try not to change. Ah, hm, yes, that's a good point that I didn't notice when copying that Policy recommendation over from the recommendations on init scripts. The obvious concern here is that multiple packages could use the same service name, and making the service name match the package name reduces that risk considerably. But I think I agree that staying consistent with upstream is more important than adopting that policy in a strong sense. Do you have a suggestion for alternative wording? I think we still need to say something about matching the name of the init script if any, and if upstream doesn't provide a service unit, it seems reasonable to use the name of the package (but maybe that should be encouraged rather than recommended?). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#949390: Newly created package usernames should begin with an underscore
Sean Whitton writes: > On Sun 05 Jan 2020 at 11:33PM +01, Philipp Kern wrote: >>> --- a/policy/ch-opersys.rst >>> +++ b/policy/ch-opersys.rst >>> @@ -231,7 +231,10 @@ starting at 100. >>> >>> Apart from this we should have dynamically allocated ids, which should >>> by default be arranged in some sensible order, but the behavior should >>> -be configurable. >>> +be configurable. When maintainers choose a new hardcoded or dynamically >>> +generated username for packages to use, they should start this username >>> +with an underscore. This minimizes collisions with locally created user >>> +accounts. >>> >>> Packages other than ``base-passwd`` must not modify ``/etc/passwd``, >>> ``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``. > Seconded. > Filing a separate bug for this as we ought to get it into the next > Policy release to avoid creating any more cases that have to be migrated. Seconded as well. I don't see any reason why this part can't go in now. The one thing that I think might be worth adding to this is to carve out an explicit exception for users starting with systemd-*, since we're unlikely to rename those and it seems reasonable to reserve that namespace for the systemd project (which is somewhat unique in the number of low-level users that it wants to create). But we can deal with that in a separate bug; this is only a should, so it doesn't require the systemd maintainers do something different with new systemd users. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#949007: debian-policy: Typo in example
Control: tags -1 pending
Niels Thykier writes:
> In
> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
> we find the following example:
> """
> Examples of valid use of the gain root command:
> # sh-syntax (assumes set -e semantics for error handling)
> $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
> # perl
> my @cmd = ('some-cmd', '--which-requires-root');
> unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
> system(@cmd) == or die("@cmd failed");
> """
> The Perl code is invalid. There is missing a 0 after "==" and before
> "or die(...)".
Thanks! Fixed for the next release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948275: is Debian POSIX compliant?
Harald Dunkel writes: > If Debian introduces a new feature, changes an API or something like > this, breaking POSIX compliance, is this a bug? Maybe? For the most part, it would be an upstream bug, and Debian would likely follow whatever upstream decided to do. It's not a Debian Policy violation in most situations. That said, my guess is that both Debian packagers and upstream would normally be sympathetic to a POSIX compliance bug that broke real-world software. > I grew up with several UNIXes listed on the compliance web page. I never > understood why df and others had to work different on some Linux > distros. Showing disk usage in 512-byte units is completely unhelpful to human beings. > IMHO this set of common basic functionality is *the* strength of Unix > over others. > Having Debian on the list would be a big achievement. There is basically no chance whatsoever that Debian will pursue formal POSIX validation. Among other things, it costs substantial amounts of money (since this is how the relevant organization supports itself), which Debian is highly unlikely to spend on that purpose. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948275: is Debian POSIX compliant?
Harald Dunkel writes: > I haven't found it mentioned in the policy manual, so I wonder if Debian > is supposed to be POSIX compliant (unless noted otherwise)? IMHO a "it > goes without saying" is not sufficient. > Is it safe to assume that POSIX code works? Simon provided the practical answer, which is that POSIX code will probably work but you may have to configure individual tools in non-standard ways if you need very precise adherence to the letter of the standard. The formal answer is that no, Debian does not attempt to pass any sort of POSIX compliance test suite and is not attempting to be POSIX-compliant in any formal sense. I believe that this is the list of formally-certified POSIX operating systems: https://www.opengroup.org/openbrand/register/ I believe EulerOS may be a Linux derivative; other than that, there are no Linux distributions on that list. There's more information here: https://unix.stackexchange.com/questions/522413/why-are-most-linux-distributions-not-posix-compliant -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948115: Revise init script Policy based on GR result
Lorenzo Puliti writes: > I wonder if it make sense to encourage or even recommend to use the > interpreter in /lib/init/init-d-script for writing init scripts. > Or maybe just citing that there is an interpreter and say that > it's the preferred way to create init scripts, I don't know.. > Anyway the interpreter would make init scripts more declarative, consistent > and easier to maintain in the long run. If folks working on future support for init scripts thinks that's a good idea, it sounds good to me. But we should move that proposal to a separate bug, since it's a bit far afield of this specific change. Please file a separate bug against debian-policy if you think this is a good idea so that we can track it. Thanks! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Guidance on solving the username namespacing problem
Colin Watson writes: > As Simon said, EF00-FFEF = 61184-65519 covers more than just netplan > (https://salsa.debian.org/debian/base-passwd/blob/master/README), and > several of the IDs allocated there in the vaguely recent past are hard > to change (their rationales included "needs to be the same across > multiple machines"), so I don't think we can use the existing systemd > range - it needs to be adjusted for Debian at least to some extent. I'm > not prepared to cede all of 64000-64999 to systemd; perhaps it would > have been better if base-passwd had started at 6 instead, but we're > here now. Oh, whoops, I misread and didn't double-check. Yes, we definitely don't want to stomp on the 64000 range that we've been using for forever. Apologies for the confusion. > The rate of static allocations in 6-64999 is low enough that I'm not > concerned in principle about carving off a slice of it for dynamic > allocations by systemd-sysusers, and in any case I wasn't expecting to > ever need to allocate more static IDs under 64000 (netplan was before my > time). Perhaps we could start by reserving 61184-63433, given the > netplan allocation? Yes, it's a bit arbitrary, but also not really all > that stingy, and base-passwd's allocations are meant to be permanent > even if the package has been removed (since we can never guarantee that > it's been removed from users' systems). This sounds good to me. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Guidance on solving the username namespacing problem
Philipp Kern writes: > I fear that we might need a local policy hook for migrations. If we end > up renaming users that are actively referenced elsewhere, there might be > cleanup tasks that need to be performed in lockstep. > At the same time I'd strongly suggest that we do not go the way of > distinguishing between the old user already being present on a machine > and a new package install. That's a divergence that becomes actively > harmful when you try to manage a set of machines. Right, I think we should start by saying that all packages that already create a user can keep using the user they are currently using for now, and stop the bleeding by setting a requirement on newly-created users going forward. Then we can separately figure out what to do about the transition, if anything. > As I see it it isn't even guaranteed that services will have a dash, > which is quite unfortunate. That would already make them way less likely > to collide. Presumably we would not want to draw a distinction between > "contains a dash and thus does not need an underscore" and "needs an > underscore prefix to disambiguate", even though that would feel like an > easier sell as it would be a behavior change for likely significantly > less services. :/ I think starting everything with an underscore is best. Talking systemd upstream into using the underscore prefix seems like the best of all worlds to me, if they'll go for it. > Patching for Debian-specific behavior seems to be against the spirit of > cross-distro reusability. So that question should be posed to systemd > upstream and then we should decide based on the response? That sounds right to me. > It looks like the range must be contiguous, as it is compiled in[1]. > What are the preexisting ones apart from netplan that you have in mind? > It feels like systemd's boundaries are pretty arbitrary (0xEF00 to > 0xFFEF) but at the same time we might want to reserve a range for it in > policy - given that right now it is effectively squatting in that range? Yes. We should also coordinate this with Colin as the base-passwd maintainer. Let me cc him explicitly. It's possible that we can just use the existing systemd range, provided that we can find some workable approach for netplan. >> This should probably go somewhere near §9.2.2 "UID and GID classes": >> it applies to future allocations in the 100-999 and 6-64999 ranges, >> and maybe to future allocations in the 0-99 range (although I don't >> think we should be migrating existing low-uid hard-coded names like >> games and proxy to _games and _proxy). > That sounds fine to me too, although I wonder about placement. You are > right that it's technically about the system-assigned ranges. At the > same time it's also somewhat of a principle that might go into §9.2.1, > as that already talks about the importance of UID allocation wrt local > administration policies. 9.2.1 feels like the right spot to me. I think that's close to 9.2.2. We could also reiterate that guidance in 9.2.2. >> --- a/policy/ch-opersys.rst >> +++ b/policy/ch-opersys.rst >> @@ -228,13 +228,16 @@ purpose for which they are allocated. This is a >> serious restriction, and >> we should avoid getting in the way of local administration policies. In >> particular, many sites allocate users and/or local system groups >> starting at 100. >> >> Apart from this we should have dynamically allocated ids, which should >> by default be arranged in some sensible order, but the behavior should >> -be configurable. >> +be configurable. When maintainers choose a new hardcoded or dynamically >> +generated username for packages to use, they should start this username >> +with an underscore. This minimizes collisions with locally created user >> +accounts. >> >> Packages other than ``base-passwd`` must not modify ``/etc/passwd``, >> ``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``. >> >> .. _s9.2.2: This part looks good to me. >> @@ -256,13 +259,14 @@ The UID and GID numbers are divided into classes as >> follows: >> 100-999: >> Dynamically allocated system users and groups. Packages which need a >> user or group, but can have this user or group allocated dynamically >> and differently on each system, should use ``adduser --system`` to >> create the group and/or user. ``adduser`` will check for the >> existence of the user or group, and if necessary choose an unused id >> -based on the ranges specified in ``adduser.conf``. >> +based on the ranges specified in ``adduser.conf``. Usernames in this >> +range should be prefixed with an underscore. I think this is too strong, since it implies that all packages that already create users should change, and I don't think we've thought through the implications of that yet. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944920: Revise terminology used to specify requirements
Sam Hartman writes: > One question: > +The Release Team may, at their discretion, downgrade a Policy requirement > +to a Policy recommendation for a given release of the Debian distribution. > +This may be done for only a specific package or for the archive as a > +whole. This provision is intended to provide flexibility to balance the > +quality standards of the distribution against the release schedule and the > +importance of making a stable release. > I wonder if that should be can (or is permitted) rather than may. Good point. I agree with your analysis and will change this in my draft version to "The Release Team can". -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948115: Revise init script Policy based on GR result
Sam Hartman writes: > I've reviewed your patch. > It looks good. > One minor suggestion: > +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should > +be supported by all init scripts. Supporting ``status`` is recommended but > +not required. The ``reload`` and ``try-restart`` options are optional. > How about supporting status is encouraged. > At this point in the game, do we really want people opening bugs because > an init script doesn't support status? > Besides that, LGTM. I agree with that change and will make that in my version. Other folks reviewing this patch, please consider that change as made when deciding whether to second (and let me know if you object to that change). Thank you for the review! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Guidance on solving the username namespacing problem
Philipp Kern writes: > OpenBSD rather successfully standardized on the underscore prefix to > eliminate this conflict altogether. I would like that we recommend the > same thing. I agree. > The main question that has been raised was how to manage the migration. I agree with this too. I'm happy to have Policy standardize this convention ASAP for newly-created users and then think at more leisure about whether (and if so, how) to migrate existing users. > I think the priority should be on stopping the bleeding and new users > should follow a consistent scheme, but I understand how without a > migration plan we just end up with "one more scheme" (even if it might > be the most popular now except using none at all[1]). In this particular case, I don't think standardizing one of the many schemes in use would cause problems over the current situation even if we don't go back and make everything consistent. > I tried to raise this issue in [2] a year ago, but I think I don't know > how to even start drafting a policy snippet about this. Would it be > sufficient to just mandate "In order to avoid collisions with accounts > created by the system administrator, usernames created by packages > should start with an underscore." (assuming we could get a rough > consensus for something like that) in 9.2.1 for now? Yes. I think we should say something about how packages that started creating users before this recommendation was added don't need to change the name of that user (until we figure out a migration strategy). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948115: Revise init script Policy based on GR result
Package: debian-policy Version: 4.4.1.2 Severity: important Per recent (non-BTS) discussion, this patch is a first draft at reconciling Policy with the recent GR result. Summary of changes: * Change section headings and anchors to reflect the more general topic * Add recommended naming convention for service units * Encourage including an init script if there is no service unit * Describe including an init script alongside a service unit as optional * Recommend appropriate naming of an init script alongside a service unit * Remove recommendation to include an init script * Use init script rather than initscript consistently * Move some things around that belong more naturally in other sections * Be consistent about saying update-rc.d is a requirement * Remove the section on alternate init systems, which is now not relevant Policy itself has no links to the previous anchors. This might break external links; let me know if you feel like that's a larger issue than I thought it was and we can look at keeping the old (but pretty wildly inaccurate) anchors. diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 4551196..47d9fe4 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -315,46 +315,53 @@ set to this value. The Debian autobuilders set HOME to ``/nonexistent`` so that packages which try to write to a home directory will fail to build. -.. _s-sysvinit: +.. _s-services: -System run levels and ``init.d`` scripts - +Starting system services + -.. _s-etc-init.d: +.. _s-services-intro: Introduction -The ``/etc/init.d`` directory contains the scripts executed by ``init`` -at boot time and when the init state (or "runlevel") is changed (see -:manpage:`init(8)`). - -``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 uses symlinks in -``/etc/rcn.d`` to decide which scripts to run and in which order; see -the ``README.runlevels`` file shipped with ``sysv-rc`` for -implementation details. Other alternatives might exist. - -Maintainer scripts must use ``update-rc.d`` as described below to -interact with the service manager for requests such as enabling or -disabling services. They should use ``invoke-rc.d`` as described below -to invoke initscripts for requests such as starting and stopping -service. +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. + +If the package does not include a service unit (if, for example, no one +has yet written one), including an init script, as described below, to +start the service is encouraged. + +Packages including a service unit may optionally include an init script to +support other init systems. In this case, the init script should have the +same name as the ``systemd`` service unit so that ``systemd`` will ignore +it and use the service unit instead. Packages may also support other init +systems by including configuration in the native format of those init +systems. + +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. + +The sections below describe how to write those scripts and configure those +symlinks. .. _s-writing-init: Writing the scripts ~~~ -Packages that include system services should include ``systemd`` service -units to start or stop those services. See :manpage:`systemd.service(5)`. - -To support other init systems, packages that include daemons for system -services should place scripts in ``/etc/init.d`` to start or stop those -services at boot time or during a change of runlevel. These scripts should -be named ``/etc/init.d/package``, and they should accept one argument, -saying what to do: +Init scripts are placed in ``/etc/init.d``. In the common case that a +package starts a single service, they should be named +``/etc/init.d/package``. They should accept one argument, saying what to +do: ``start`` start the service, @@ -381,10 +388,9 @@ saying what to do: ``status`` report the current status of the service -The ``start``, ``stop``, ``restart``, and ``force-reload`` options -should be
Re: Proposal for next steps for systemd-related policy
Sam Hartman writes: > I haven't been following the consensus around making service units more > recommended. Ignoring that discussion, but folding in the GR: > Maintainers are recommended to install at least one of a service unit or > init script. Maintainers are encouraged to install an service unit and > may install an init script. > But if you've gotten to a point where service units are recommended all > the time (no service unit but an init script is a bug) then: Maintainers > are recommended to install a service unit. If maintainers do not > install a service unit, they are encouraged to install an init script; > in other situations installing an init script is optional. Thinking about this some more, and re-reading the text of the GR, this sounds correct to me as well. I'm not sure that Policy is currently structured in such a way as to make saying this straightforward, but I'm taking a look now and will create a bug with a patch for discussion and review. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#944920: Revise terminology used to specify requirements
Sean Whitton writes: > Let's definitely reconsider those 'must' requirements in response to > this work, but let's not commit ourselves to the idea that it's always a > bug for the Release Team's conception of an RC bug, and Policy 'must' > requirements, to disagree. > The Release Team's conception of RC bugs, and the text of Policy, are > generated and updated by different processes, for different purposes. I > think Debian benefits from that diversity of normative processes, and it > would harm that to try too hard to keep the output of the two processes > in perfect sync. Yes, that's put better than I put it. Thank you. I was too focused on the fact that I suspect we'll find some musts that are too aggressive, but indeed, allowing these things to differ is part of why I'm proposing explicit language to allow the Release Team to downgrade requirements to recommendations. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944920: Revise terminology used to specify requirements
Russ Allbery writes: > I agree, but let's also fix existing incorrect wording. I reviewed > every instance of may and optional in Policy, and I think this larger > diff will make wording (mostly) consistent. I've tried not to change > the sense of any of these Policy statements (even though a few are > questionable and should probably be revisited). Here is an updated version of this patch, including the upgrading checklist entry. I tried using a word diff, but I think the line diff is more readable and easier to understand. I at least found it easier to understand the wording changes in that format (maybe this is just my long familiarity with reviewing line diffs). I think this is ready for seconds, assuming that one agrees with the three places that I made semantic changes (/usr/lib64, init-system-helpers, and deciding on encouraged for debian/missing-sources). Most of this diff is changing normative "may not" phrasings to "must not" or some other equivalent, and changing other uses of "may" to "could" or other wordings. This retains the statement about the release team's role in changing the severity of Policy requirements, since I think that was the outcome of the side conversation. I'll work on an appendix accumulating all Policy requirements in a separate patch. diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst index b8ba081..e37ebee 100644 --- a/policy/ch-archive.rst +++ b/policy/ch-archive.rst @@ -329,8 +329,8 @@ management tools. the user doesn't select anything else. It doesn't include many large applications. -No two packages that both have a priority of ``standard`` or higher -may conflict with each other. +Two packages that both have a priority of ``standard`` or higher must +not conflict with each other. ``optional`` This is the default priority for the majority of the archive. Unless diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst index 74a1690..f1e518e 100644 --- a/policy/ch-binary.rst +++ b/policy/ch-binary.rst @@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts must provide the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``. All packages which supply an instance of a common command name (or, in -general, filename) should generally use ``update-alternatives``, so that -they may be installed together. If ``update-alternatives`` is not used, +general, filename) should generally use ``update-alternatives`` so that +they can be installed together. If ``update-alternatives`` is not used, then each package must use ``Conflicts`` to ensure that other packages are removed. (In this case, it may be appropriate to specify a conflict against earlier versions of something that previously did not use diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 0d7a3e9..8d43130 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, architectures, files or anything else) or version numbers, or between the characters of multi-character version relationships. -The presence and purpose of a field, and the syntax of its value may +The presence and purpose of a field, and the syntax of its value, may differ between types of control files. Field names are not case-sensitive, but it is usual to capitalize the @@ -553,7 +553,7 @@ The three components here are: ``epoch`` This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then the -``upstream_version`` may not contain any colons. +``upstream_version`` must not contain any colons. Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change @@ -572,19 +572,19 @@ The three components here are: respect to the ``upstream_version`` is described below. The ``upstream_version`` portion of the version number is mandatory. -The ``upstream_version`` may contain only alphanumerics [#]_ and +The ``upstream_version`` must contain only alphanumerics [#]_ and the characters ``.`` ``+`` ``-`` ``~`` (full stop, plus, hyphen, tilde) and should start with a digit. If there is no ``debian_revision`` then hyphens are not allowed. ``debian_revision`` This part of the version number specifies the version of the Debian -package based on the upstream version. It may contain only +package based on the upstream version. It must contain only alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop, tilde) and is compared in the same way as the ``upstream_version`` is. It is optional; if it isn't present then the ``upstream_version`` -may not contain a hyphen. This format represents the case where a +must not contain a hyphen. This format represents the case
Bug#944920: Revise terminology used to specify requirements
Sean Whitton writes: > On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote: >> is being used.) You must not include the ``/etc/rcn.d`` directories >> -themselves in the archive either. (Only the ``sysvinit`` package may do >> -so.) >> +themselves in the archive either. (Only the ``init-system-helpers`` >> +package may do so.) > Likewise, isn't this a semantic change? This is, but I think it's a bookkeeping change. Those directories are in init-system-helpers rather than sysvinit in the archive right now, and that clearly shouldn't be a policy violation. Ideally it should probably be in a separate commit, but in looking at this again I also want to change "may do so" to "is permitted to do so." I can break it out if needed, but I'd rather commit it as part of this set of changes (and will document it separately in debian/changelog; I don't think it warrants adding to upgrading-checklist since it only affects one set of maintainers who already know). >> @@ -797,14 +798,13 @@ the upstream tarball. In order to satisfy the DFSG >> for packages in >> 2. include a copy of the sources in the ``debian/missing-sources`` >> directory. >> >> -There is an optional convention to organise the contents of >> -``debian/missing-sources`` in the following way. For a sourceless >> -file ``foo`` in the subdirectory ``bar`` of the upstream tarball, >> -where the source of ``foo`` has extension ``baz``, the source is to be >> -located at ``debian/missing-sources/bar/foo.baz``. For example, >> -according to this convention, the C source code of an executable >> -``checksum/util`` is to be located at >> -``debian/missing-sources/checksum/util.c``. >> +Package maintainers are encouraged to use the following convention to >> +organize the contents of ``debian/missing-sources``: for a sourceless file >> +``foo`` in the subdirectory ``bar`` of the upstream tarball, where the >> +source of ``foo`` has extension ``baz``, the source is to be located at >> +``debian/missing-sources/bar/foo.baz``. For example, according to this >> +convention, the C source code of an executable ``checksum/util`` would be >> +located at ``debian/missing-sources/checksum/util.c``. > I don't think this should be strengthened to something Policy > encourages, or if it should, we should discuss it in a separate bug. So > I'd like to suggest using none of the magic words in this paragraph, > just starting it with "There is a convention to organise ..." I think this is a change where the distinction between optional and encouraged is valuable and this would have been written as encouraged if we had that concept. There's not much point in a convention unless we advise maintainers to follow it, and that seems like an appropriate use of Policy advice. Does that make sense? I can revise it if you don't like it after that explanation, but it feels perfect for "encourage." -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Proposal for next steps for systemd-related policy
Simon McVittie writes: > Do you mean "systemd features", or do you mean system services more > generally? I'm hopeful that we can solve the more general problem, or at least make forward progress on it, since as you mention we've had this problem for years and have worked around it in various ways. This is primarily bringing an existing problem to the fore. One of the open questions that I have, and that I think we'll need to talk about, is what the UI should look like. I think it should be possible to install a package that depends on a system facility that isn't available, but we need to somehow warn people that the thing they're trying to do won't work as-is, and ideally figure out some way for reasonable things to happen in chroots, containers, and other restricted environments. Most of the ways that I can tentatively imagine we could approach this problem would require changes to dpkg, apt, and aptitude; I don't think package dependencies, even used creatively, will quite work here. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#941803: debian-policy: dependencies on font packages
Stephen Kitt writes: > I’m attaching a revert and an update to the footnote (against the next > branch): Thanks! Applied for the next release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Clarification about special characters in version and some suggestions
Florian Weimer writes:
> But until these versions are explicitly described as invalid, shouldn't
> the comparison algorithm cover them, so that different implementations
> behave in the same way?
Oh, definitely. And I believe the textual description does cover them;
there just aren't any examples. So maybe we should add examples with a
note that hopefully no one is using constructs like that.
> Other corner cases are empty epochs and zero epochs. And while not
> really being a corner case in the Policy, APT compares ~ and ~0 as equal
> at the end of a version string:
> >>> apt_pkg.version_compare('1~', '1~0')
> 0
That's also a good thing to mention. There are some oddities with -0 as a
Debian revision too, if I remember correctly.
Could someone open a bug against debian-policy for this so that we don't
lose track and can hash out some of these details?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Clarification about special characters in version and some suggestions
Samuel Henrique writes: > I suggest making it more explicit by adding an example to it and > explicitly writing the precedence of them, I did some tests with dpkg > --compare-versions to confirm and found out that that is (n being a > number): > "~ - n + ." eg.: 1.0~0-1 < 1.0-0-1 < 1.0-1 < 1.0+0-1 < 1.0.0-1 Ideally no one should ever use 1.0-0-1, so I'm a little dubious about including it, but otherwise having examples seems like a good idea. > And when symbols are repeated (tilt becomes the outlier): > "~~ ~ - -- n + ++ . .." eg: 1.0~~0-1 < 1.0~0-1 but 1.0--0-1 > 1.0-0-1 (and > same for + and .) Likewise here, 1.0--0-1 is something no one should use. I'm not sure it's worth explicitly adding examples for duplicate symbols other than for ~, which is the only place where I think this is useful or likely to come up. (There is an exaple for ~~ already, but it may not be the easiest to follow.) > The other suggestion, which is related to the issue I reported to > repology; > What if the policy started stating (or be more explicit if it already > states) that ~ and - areexclusive for pre-release versions like > alpha|beta|rc and + and . are for modifiers that arepost-release, like > dfsg e git snapshots? I'm not sure that I understand. Policy explicitly states that ~ sorts before any other character, so by definition it sorts earlier than the number without ~ appended. If you're saying that those characters should be reserved for specific semantic purposes, I don't think that's a good idea. There are various tricky versioning situations where one really needs to use the full sorting capabilities. The intent is for these characters to be functional, not to have any specific meaning in the version. Also, "." isn't really a modifier in that sense. It's normally part of the upstream version, and I wouldn't recommend a Debian packager add a period to the version, since that's likely to be confusing. Generally we restrict ourselves to using ~ and +. (Maybe it would be a good idea to say that in Policy.) Lintian already warns about using .dfsg instead of +dfsg. Possibly we should say something about that in Policy as well, since .dfsg is almost always wrong because 1.0.dfsg1 >> 1.0.1. > The main idea I'm trying to chase is to make it formal that when parsing > a package version one can always assume that any package with ~ or - > before its last hyphen is packaging a version that is less than the > "plain one" (the numeric part of it before the modifiers), and that it's > the inverse for the + and . modifiers, in which the given package > contains that "plain" version plus some other things/changes (dfsg or > git). With the caveat about ".", I think this is just a restating of the sorting order, which is correct. That is the order in which the versions will sort. If you want to make a stronger assumption that a package with ~ or + is based on an upstream release with that component removed, I think that assumption may be too strong (for instance, it's violated by the +really convention documented in Policy). > I've also seen people setting up d/watch to deal with this and I believe > it could be avoided by having it as a policy and changing uscan to > follow it. I'd have to hear more about the specific use case you had in mind. uscan already supports @DEB_EXT@ and dversionmangle=auto, which I think does a lot of what you want. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Proposal for next steps for systemd-related policy
Russ Allbery writes: > Right, what I think is in scope for Policy is advising packagers on > which readiness signaling mechanism to use if upstream supports several. > If one is relatively new to packaging daemons, this may not be something > on one's radar to look at, but there are substantial, if subtle, > advantages to using Type=notify if upstream already supports it. > (Type=dbus is fine, of course, and we probably shouldn't doument that as > well, although my guess is that things that register with D-Bus are more > likely to already know about these subtleties.) That was supposed to be "we probably should document that as well." I think I edited that sentence too much. Sorry about the confusion. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Proposal for next steps for systemd-related policy
Simon McVittie writes: > On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: >>We probably also want to recommend Type=notify where possible and >>Type=exec where not, over Type=forking, when the daemon supports >>that. > I'm not sure what you mean by "where possible" - it'll usually be > possible to implement Type=notify (even if a libsystemd dependency is > unacceptable or not feasible in the implementation language, the > protocol is designed to be reimplementable) but it won't always be > useful. I mean something relatively modest. If upstream already supports systemd's notification protocol, I think we should recommend that as the best choice. (I'm dubious about asking Debian packagers to add support.) > Type=exec doesn't provide a way for the daemon to signal that it has > opened listening sockets or done whatever else is necessary for units > that depend on it to be able to start without error, so daemons that > might be depended on by other units will normally need to use either > Type=notify, Type=dbus or Type=forking, then make sure they do basic > setup (listen on sockets, etc.) before they notify, request their D-Bus > names or do the traditional double-fork daemonization trick (whichever > is appropriate for their Type). Ah, yes, it's a good point that Type=forking when properly implemented is somewhat better than Type=exec on getting dependency ordering correct. But this is the sort of nuance that I think we should document somewhere. Getting Type=forking right is surprisingly complicated. The best documentation for how to do that I've seen is, ironically, in the systemd documentation, in daemon(7). If the daemon double-forks and exits and then binds to network sockets and so forth, which is common, the advantages over Type=exec are basically lost. > However, I don't think this is necessarily in-scope for Policy? > Implementing readiness-signalling if required seems like it might be the > sort of "don't be buggy" requirement that shouldn't necessarily need to > be said explicitly. Right, what I think is in scope for Policy is advising packagers on which readiness signaling mechanism to use if upstream supports several. If one is relatively new to packaging daemons, this may not be something on one's radar to look at, but there are substantial, if subtle, advantages to using Type=notify if upstream already supports it. (Type=dbus is fine, of course, and we probably shouldn't doument that as well, although my guess is that things that register with D-Bus are more likely to already know about these subtleties.) > I say "when run from a systemd service" so that services like > dbus-daemon meet this recommendation - by default it double-forks for > compatibility with LSB-style init scripts and its own historical > behaviour, but the systemd unit dbus.service runs "dbus-daemon --nofork" > which disables the double-fork code path, and I think that's a perfectly > good implementation of what we want. Yes, completely agreed. >>- DynamicUser without useradd of a system user > One warning for this one is that users referred to in dbus-daemon > system.d/*.conf snippets, typically , > currently need to be pre-created by sysusers.d, useradd or equivalent > (because dbus-daemon resolves usernames to uids during its own > startup/reload, to populate internal data structures that are all > designed in terms of uids). Other references to users in non-D-Bus > configuration might well behave similarly. Right, there are a lot of subtleties for when DynamicUser can and can't be used that we'll need to hash out and document. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
