Bug#970234: consider dropping "No hard links in source packages"

[Helmut Grohne]

Hi Russ,

On Thu, Sep 22, 2022 at 07:20:00PM -0700, Russ Allbery wrote:
> 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.
>  

Seconded.

Helmut


signature.asc
Description: PGP signature

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 970234 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 970234 = normative
Usertags were: normative proposal.
Usertags are now: normative.
> tags 970234 = patch
Bug #970234 [debian-policy] consider dropping "No hard links in source packages"
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
970234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970234
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#970234: consider dropping "No hard links in source packages"

[Russ Allbery]

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)  

>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

[Russ Allbery]

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)  

>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 would treat the
+following dependency::
+
+foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 1020267

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> tags 1020267 = pending
Bug #1020267 [debian-policy] Essential packages only provide functionality 
after being configured
Added tag(s) pending; removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1020267: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020267
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Russ Allbery]

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.”
> ()

> 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)  

Bug#1020267: Essential packages only provide functionality after being configured

[Russ Allbery]

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)  

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 823256

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> tags 823256 = pending
Bug #823256 [debian-policy] debian-policy: Update maintscript arguments with 
dpkg >= 1.18.5
Added tag(s) pending; removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
823256: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823256
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Russ Allbery]

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)  

Bug#1020267: Essential packages only provide functionality after being configured

[Guillem Jover]

Hi!

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,
Guillem


signature.asc
Description: PGP signature

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 19:36:36 -0700, Russ Allbery wrote:
> 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.

If you omit the field in the source stanza, then both dpkg-genchanges
and lintian will complain about it with a warning.

> 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.

Some of the fields found in the debian/control binary stanzas inherit
their values (if omitted) from the source stanza, otherwise they get
overridden.

The binary packages use a combination of information from
debian/changelog, the source stanza and their own binary stanza.

For non-binary packages (sources) or artifacts (say .buildinfo, or
byhand objects) there are no binary stanzas, so no information is
taken from them.

If you specify a Section field for every binary stanza, and omit it
from the source stanza, then dpkg-genchanges will have to fill it with
«-» when generating the .changes file.

If you omit the Section field from both the source stanza and one of
the binary stanzas, then that binary package will contain no Section
field, dpkg-genchanges will warn about both missing fields, and it
will fill the section value as «-» for that binary package on the
.changes file.

Thanks,
Guillem

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 21:42:37 -0700, Russ Allbery wrote:
> "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.

I also committed a changed based off this patch to dpkg's
deb-changelog(5) man page, which I mentioned some time ago I'd do,
but probably didn't as I thought the patch here still had the issue
discussed at the time.

Thanks,
Guillem

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Guillem Jover]

Hi!

On Thu, 2022-09-22 at 14:26:38 +0900, Charles Plessy wrote:
> Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> > 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.

Idem.

> > 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.
> 
> 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.” ()

In the end nothing will match exactly, and we need to choose some
terminology. In this case, as previously mentioned, «stanza» has the
good properties of not usually applying to prose, being short, distinct
from the other terms and the less ambiguous of them all. It also makes
constructing sentences to describe things less cumbersome.

> I do not mind the word "section".  It is the term used in the manual
> page "systemd.syntax" that describes systemd's unit files, which means
> that readers may be already familiar with the concept.  One could argue
> that its definition in Simple English
> (, “A section of a thing or
> place is a part of it”) would allow a reader to think that a Field is
> also a section, but I feel it is unlikely to happen.  This said, one big
> disadvantage of "section" is that when searching for this word in a
> document, there may be a lot of noisy hits such as "refer to section xyz
> for details".

The problems with section, is that as you mention is not very
searchable, but worse we already have a field with the same name!

> I understand about avoiding ambiguity, but in my opinion it is the price
> to pay to be able to translate information into simple words from
> English to non-European languages.  Although the Policy itself is not
> going to be translated, I think that it can be advantageous if its
> contents can be discussed in simple words in people's native languages.

As a non-native speaker, and a translator, I agree having clear
wording in the original text is important, as otherwise that tends to
make translation work harder. But then, part of that work is to find
or create terminology, in many cases not existing yet in the
translated language, that might be suitable there, trying several terms
that might not necessarily be direct translations.

For a translation anecdote related to finding the right terms, when
triggers got introduced, and having to translate them to Catalan, we
initially used «gallets» (which would be the direct translation). But
when reading them that was bothering several of us as it sounded weird,
it could be read as “small roosters” («gall» being rooster, and «ets»
forming the plural diminutive), or being too close to «galets» which is
a type of pasta used for example in «sopa de galets» ("galets" soup). We
then switched to «activadors» which sounds way nicer, even though it's
not a direct translation. But if we had to translate the spec today,
that would be annoying as it uses «activating» all over the place, so
perhaps using «disparador» would be better. So, in the end this is a
process too, and terms can be changed if they are deemed confusing or
not helping convey the meaning. And in some others, you just need to
simply create new terminology, and describe what it means in specific
contexts.


For example for Catalan/Spanish «stanza» is simply «estrofa» which
seems like a nice term to use here.

Thanks,
Guillem

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 21:21:23 -0700, Russ Allbery wrote:
> Here is a patch to fix this wording in Policy.  I think it's ready for
> seconds.

> >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 `

For deb-changes(5) I switched from “(required)” to “(required in
context)”, but I don't think there's any similar precedent in the
Debian policy. Just noting here mostly for reference or as possible
inspiration :), and not as any kind of blocker or conditional on
seconding.

>  
>  -  :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.)

Hmm, I guess that's fine, but perhaps it would be more precise and/or
future-proof to state instead that the field is only present if there
are binary packages included (or will be missing if they are not
present, but based on the binary packages instead of the source
packages)? Things that cross my mind might be say .changes that include
only byhand entries or similar, dunno.

> […] 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.

Ditto.

>  
>  .. _s-f-Installed-Size:

Thanks,
Guillem

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 18:52:22 -0700, Russ Allbery wrote:
> Here is a patch that I believe implements that, and which I think is ready
> for seconds.

> >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-preinst* install *old-version*
> +   *new-preinst* install *old-version* *new-version*
>  
> Error unwind:
>  
> .. parsed-literal::
>  
> -   *new-postrm* abort-install *old-version*
> +   *new-postrm* abort-install *old-version* *new-version*
>  
> If this fails, the package is left in a "Half-Installed" state,
> which requires a reinstall. If it works, the packages is left in
> @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-postrm* failed-upgrade *old-version*
> +   *new-postrm* failed-upgrade *old-version* *new-version*
>  
> If this works, installation continues. If not, Error unwind:
>  
> @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 09:21PM -07, Russ Allbery wrote:

> 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:

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 06:52PM -07, Russ Allbery wrote:

>
> 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-preinst* install *old-version*
> +   *new-preinst* install *old-version* *new-version*
>
> Error unwind:
>
> .. parsed-literal::
>
> -   *new-postrm* abort-install *old-version*
> +   *new-postrm* abort-install *old-version* *new-version*
>
> If this fails, the package is left in a "Half-Installed" state,
> which requires a reinstall. If it works, the packages is left in
> @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-postrm* failed-upgrade *old-version*
> +   *new-postrm* failed-upgrade *old-version* *new-version*
>
> If this works, installation continues. If not, Error unwind:
>
> @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-postrm* abort-upgrade *old-version*
> +   *new-postrm* abort-upgrade *old-version* *new-version*
>
> If this fails, the old version is left in a "Half-Installed"
> state. If it works, dpkg now calls:

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Debian Bug Tracking System]

Processing control commands:

> tag -1 + pending
Bug #992136 [debian-policy] Don't require Standards-Version field when only 
udebs Standards-Version for udeb packages
Added tag(s) pending.

-- 
992136: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992136
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Sean Whitton]

control: tag -1 + pending

Hello,

On Tue 20 Sep 2022 at 06:39PM -07, Russ Allbery wrote:

> 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 `_ 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
> +`_ for more information
> +about them.
>
>  .. [#]
> Informally, the criteria used for inclusion is that the material meet

Seconded and applied, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature