Hi!

This is a followup from my comment at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#43

To summarize, we have IMO confusing naming and nomenclature for the
various control files and paragraphs/stanzas, and this is even
confusing me when having to deal with dpkg code, so I'd like to give
these more clear and unambiguous new names, and I'd very strongly
prefer to agree on the same naming for Debian policy and dpkg, to
avoid further and worse confusion (even though they currently do not
match exactly anyway, but I'd prefer to not make it worse…).

Just for reference and to give some context, I've got the following
WIP branches, trying to clarify the names in documentation and in the
API on, which I'll probably rework (split/merge) and reword as needed,
so do not take them as anything set in stone:

https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/clarify-control-filenames
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/deb822-field-types


File descriptions
-----------------

For example we have:

  * debian/control:
    policy → «Source package control file»
    dpkg   → «Debian source packages' master control file»

  * .dsc:
    policy → «Debian source control file»
    dpkg   → «Debian source packages' control file»

  * DEBIAN/control
    policy → «Binary package control files»
    dpkg   → «Debian binary packages' master control file»

These are quite confusingly close.

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/msg00002.html>.


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?


If I've missed any other problematic nomenclature, I'm happy to
discuss and update those on the dpkg side.

Thanks,
Guillem

Hello,

Can we standardise on 'stanza', please?

I thought that was already standard, and "paragraph" is for prose.

I was also thinking about whether I'd prefer paragraph or stanza, and
the latter seems more specific to deb822 "blocks", and as you say
paragraph seems more for prose.

I went for paragraph, because dpkg has some instances of it already in
docs and code (and stanza only in code), and mainly because the Debian
policy uses almost exclusively paragraph for this with a single
mention of "stanza" in a footnote to mention it's a common alias or
similar.

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.

Thanks,
Guillem

Hello,

Hmm, I see.

I think this is fine for Policy to do.

Sean Whitton <spwhitton@spwhitton.name> writes:

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.

Guillem Jover <guillem@debian.org> writes:

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.

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.

Hello,

Yes, I had this example in mind too.

Hi!

Ok, I've prepared the attached incremental patch, which only switches
from paragraph(s) to stanza(s) all over the place.

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. 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've gone one by one, but please review carefully as I might have
perhaps switched in excess!

Thanks,
Guillem

Guillem Jover <guillem@debian.org> writes:

Thanks, applied.

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.

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.

Reviewed, and also checked for remaining uses of "paragraph."  Everything
looked good.

Hi all,

while I do not want to pull the handbrake I would like to add my
minority opinion to that change:

Le Tue, Sep 20, 2022 at 04:11:43PM +0000, Russ Allbery (@rra) a écrit :

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.

If I were to redo such a specification from scratch, I would ask
non-European language speakers their opinion too.

Have a nice day,

Charles Plessy <plessy@debian.org> writes:

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.

I'm definitely interested in that opinion from anyone who is listening in!

Hi Russ,

Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :

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".  By the
way, in section 5.6.26 of the Policy, the word "stanza" is also used to
mean something else than a "paragraph".

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
(<https://simple.wiktionary.org/wiki/section>, “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".

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.

Cheers,

Hello Charles,

I think that the quoted definition rather argues against 'paragraph' --
it makes it clear that being made up of sentences, and not
non-sentences, is essential to paragraph-hood.  In other words, it only
becomes spot on if you change the core meaning into a definition of
something else.

It may yet be translated!  We have the po4a setup :)

Hi!

Idem.

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.

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

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

Charles Plessy <plessy@debian.org> writes:

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.

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.

FWIW, and knowing this is not a popularity vote, as yet another
non-native speaker-with a different first language-I also like
"stanza" and agree with Guillem's arguments.

Additionally I'd like to mention that also some software uses this
term:

/usr/share/perl5/Debian/Control/Stanza
/usr/share/perl5/Debian/Control/Stanza.pm
/usr/share/perl5/Debian/Control/Stanza/Binary.pm
/usr/share/perl5/Debian/Control/Stanza/CommaSeparated.pm
/usr/share/perl5/Debian/Control/Stanza/Source.pm
/usr/share/perl5/Debian/Copyright/Stanza
/usr/share/perl5/Debian/Copyright/Stanza.pm
/usr/share/perl5/Debian/Copyright/Stanza/Files.pm
/usr/share/perl5/Debian/Copyright/Stanza/Header.pm
/usr/share/perl5/Debian/Copyright/Stanza/License.pm
/usr/share/perl5/Debian/Copyright/Stanza/OrSeparated.pm

(That's dh-make-perl and libdebian-copyright-perl. Also
libparse-debcontrol-perl talks about "stanzas" in its documentation.)


Cheers
gregor

Hi Russ and Gregor,

thanks for your feedback,

I think that I made most of the points I was thinking about and hope
that some of them related to Simple English and jargon can be useful in
the future.  I also understand your point of view.  One final comment I
would like to make is that the format is used in other contexts, such as
Apt (using "paragraph" in https://wiki.debian.org/DebianRepository/Format),
DEP-11 (using "block" in https://wiki.debian.org/DEP-11), and probably
other files generated for the Debian archive.  I recommend to keep
producers and consumers of these files in the loop before changing
Chapter 5.  As for on which word to standardise on, I trust the Policy
Editors to make a good choice, even if it is not my favourite.

Have a nice week-end,

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1020248@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sean Whitton <spwhitton@spwhitton.name> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 16 Dec 2022 19:41:44 -0700
Source: debian-policy
Architecture: source
Version: 4.6.2.0
Distribution: unstable
Urgency: medium
Maintainer: Debian Policy Editors <debian-policy@lists.debian.org>
Changed-By: Sean Whitton <spwhitton@spwhitton.name>
Closes: 823256 953911 975631 992136 1020238 1020241 1020243 1020248 1020267
Changes:
 debian-policy (4.6.2.0) unstable; urgency=medium
 .
   [ Sean Whitton ]
   * Policy: Update alternatives system priorities for window managers
     Wording: Ansgar <ansgar@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #975631
   * Policy: Clarify udeb-only source packages are out of scope
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Holger Levsen <holger@layer-acht.org>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #992136
 .
   [ Russ Allbery ]
   * Policy: Add new-version argument to several maintainer script calls
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Seconded: Guillem Jover <guillem@debian.org>
     Closes: #823256
   * Policy: Essential packages must work only if previously configured
     Wording: Helmut Grohne <helmut@subdivi.de>
     Seconded: Santiago Vila <sanvila@unex.es>
     Seconded: Guillem Jover <guillem@hadrons.org>
     Closes: #1020267
   * Prefer "portion" to "stanza" when describing parts of the Vcs-Git
     header to avoid confusion with blocks of fields in deb822.  Thanks to
     Charles Plessy for pointing out the inconsistency.
 .
   [ Guillem Jover ]
   * Terminology fixes.  (Closes: #1020248)
     - Refer to blocks of fields in deb822 files as stanzas, not
       paragraphs.  This aligns terminology with dpkg and reduces confusion
       with text paragraphs found in, for example, the Description field.
   * Policy: Replace references to PGP with OpenPGP.  (Closes: #1020243)
   * Whitespace and quoting fixes.  (Closes: #1020238)
     - Remove trailing whitespace and convert tabs to spaces in all files.
     - Avoid use of unbalanced single quotes.
   * copyright-format: Formatting improvements.  (Closes: #1020241)
     - Put Source after Format in examples.
     - Reformat GPL examples to be more compact.
     - Use URLs rather than postal addresses in GPL examples.
     - Move the comment about where the GPL can be found on Debian systems
       to a separate Comment block in examples, rather than including it in
       the License text.
     - Apply wrap-and-sort -ast formatting to Files fields in the examples.
 .
   [ Daniel Shahaf ]
   * Add an English description of the format of bug closers in the
     changelog file, alongside the Perl-compatible regular expression.
     (Closes: #953911)
Checksums-Sha1:
 68020ea0f9df088391fed23bc80416df72e487c4 2110 debian-policy_4.6.2.0.dsc
 043fcb99be4d3d2baf8df2f8ca6de851f0f65952 553052 debian-policy_4.6.2.0.tar.xz
Checksums-Sha256:
 0a218d72f61712c86b66a1230cafde57ac73ee86f0a7994dcdc821f98c798d6f 2110 debian-policy_4.6.2.0.dsc
 9ac321d91c6f6172d73fa7f6a59559e2f6d4b764921e2334ce6f891c11dde09f 553052 debian-policy_4.6.2.0.tar.xz
Files:
 4c6e9d77f982a692fa26de9cc65a7002 2110 doc optional debian-policy_4.6.2.0.dsc
 a9019d3ec96a9c6992050ea4ffd43f96 553052 doc optional debian-policy_4.6.2.0.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmOdLJIACgkQaVt65L8G
YkAHZA//ZX0MECFXMtReEBV8qEolC+vwdewHyRLvbu9NrIRk1Wja+FuwCU1w9sP4
U1lmzDCTNkWoweme98tsqRw0umfZCQRBJAC9GEMqRFZQqEYShfYxATFiLV9ya2q9
oKt1NisN/83hrJUbd5FtR02LUVty06OaDTH+IeUa6NpoPTtY0vDrl1YXjrPMmH08
2gJwcHViR6rk6RRPZJZMRFEslkM3RyoiWecapU3oFLtscYMq+BPi4vsBhKqQ7C39
xn0M8t7hWcHzt4Kb9MT2aT89KaR7aCnvtgZZqCDvteAKdvwnnIbKJKqC9M+D8I2j
AE9zYd/6u/0zy0T74FrQ8y9SHVcGb7nY7tEGOsfJ2MekpllubxMQ4DiP3uGHbOBm
q/eyeOtxeD9kk7ONmUCkEXwIz292hRSyEh+WEr2zTf7HqEKeR6zik6UUn8oLJWCv
UCUitgdPJyUS4EYnY3n79vvIoTXuu/3LeWAvlh9k02avTeGFLEybKBg0kTV6m9z0
26OaxEFMco5XFIC7CZTeNj0LQttP+C3Pck3K7imfBr6IFNDOsEhION6JXm19AB6W
CU7BpFFiLQxuHhHSLzgIbuQE+KyywgReXUf339qQGbgD8jHeMBl6EECFaKTWPlA0
nd885fjVrXMchyj+dtQc+BOFB6EOH1sBwNjug5jbPxbjI6a6fHc=
=C64N
-----END PGP SIGNATURE-----

Hi!

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

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

In any case, I've sat down and gone over the meat of the original
report. See below.

Seems I missed another file:

  * .changes:
    policy → «upload control file» / «Debian changes file»
    dpkg   → «upload control file» / «.changes control file» /
             «Debian .changes file» / «Debian changes file»

For changes I think something like the following might be a more clear
option (and has the minor bonus of aligning perfectly on the first
words! :), with it mentioning explicitly this is about changes being
uploaded, and that it is a control file (but I'm not sure I'm entirely
convinced about it):

    * .changes:       «Debian upload changes control files»

I've also found instances of «record» and «section» referring to fields
or stanzas.

I also recalled another term that has always seemed very confusing in
context: «control information files» or «control information area». For
example in a sentence such as “the control file is a control information
file in the control information area in a .deb archive”. :) This also
seems confusing when some of the files in the .deb control member are
not really “control files” with a deb822(5) format.

My thinking has been going into calling these as the «metadata files»,
and being located in either the  «metadata part of the .deb archive» or
explicitly the «control member of the .deb archive», in contrast to the
filesystem part. In dpkg I'd be eventually switching to meta/metadata
and fsys/filesystem, from control or info and data. I've added a patch
with the proposed change, but again nothing set in stone, and I'm again
open to discussing pros/cons of this.

Attached the proposals for discussion/review, and I might again have
perhaps missed instances or similar.

Thanks,
Guillem

Guillem Jover <guillem@debian.org> writes:

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

I'm personally happy to stick with stanza.

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.

Will take a look soon!

(Right, personally I don't think I'd split one bug per patch, as long
as the patch is covering the same thing, perhaps. In this case I
pondered about opening a new one, but given the initial discussion
and context was here it seemed best to keep it together. Should have
perhaps split the stanza stuff into another report, though. :)

(In any case, hope this is all not too inconvenient!)

Sorry, rereading that paragraph it seems not clear on what I was
trying to convey. :) I meant that because I thought this could be backed
out until an upload, I guess subconsciously postponed further changes
for this (both in dpkg and here) based on that. Should have asked.

Probably more clear currently, yeah. To expand on the above, my thinking
has been for example that if we ever have a deb 3.0 format, I'd probably
like to name the members, something like: «meta.tar.*» and «fsys.tar.*»,
and that's also what I've kind of been moving the dpkg internals to
(functions, structs and similar). Also as part of the file metadata work,
I've also have pending splitting the dpkg db info/ dir into a dir that
contains things shipped by the .deb, and a dir for stuff generated by
dpkg itself, so that they cannot conflict or get overwritten or need
to be taken into account doing any of that.

Thanks,
Guillem

Hello,

We're sticking with 'stanza', and in light of that, could you confirm
that the bug is reopened in order to make additional fixes, rather than
back anything else out?

Thanks.

Hi!

In case my other replies to Russ didn't make this clear. This comment
was in reference to the various replies in the sub-thread started by
Charles, where it looked to me like whether to back that out was still
an open question for the editors.

In any case, as I mentioned, given the changes being included in the
release, I took that as indeed, sticking with the term, and that's why
I reopened and submitted the actual changes this original report was
intending on requesting. :)

As an aside I've since updated the dpkg code and docs to refer to
these as stanzas everywhere applicable.

Thanks,
Guillem

Guillem Jover <guillem@debian.org> writes:

[...]

[...]

[...]

All of these changes seem straightforward and uncontroversial to me, and
there are huge advantages to using consistent terminology between Policy
and dpkg.  I have applied all of them for the next Policy release.  Thank
you!

Please remove the following email address:  e.little598@gmail.com

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1020248@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sean Whitton <spwhitton@spwhitton.name> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 24 Feb 2024 20:39:43 +0800
Source: debian-policy
Architecture: source
Version: 4.6.2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Policy Editors <debian-policy@lists.debian.org>
Changed-By: Sean Whitton <spwhitton@spwhitton.name>
Closes: 793499 915583 1020248 1031403
Changes:
 debian-policy (4.6.2.1) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Standardize terminology with dpkg.  (Closes: #1020248)
     - Use 'stanza' for each section of a multi-section control file, such as
       the source package template control file (debian/control).
     - Use standardized naming for binary package control files, source
       package control files (.dsc), source package template control files
       (debian/control), and upload changes control files (.changes).
     - Refer to members of the control member of the .deb archive as
       'package metadata'.
   * Update Installed-Size algorithm used by dpkg (Closes: #793499).
 .
   [ Stéphane Blondon ]
   * New Debian-specific Sphinx style (Closes: #915583).
 .
   [ Max-Julian Pogner ]
   * Fix missing quotes in dpkg-divert examples. (Closes: #1031403)
Checksums-Sha1:
 1ca66544071b0942fdbd0f2fc155ff98e0794349 2136 debian-policy_4.6.2.1.dsc
 0194a75ba91649127927fc24df894f4c2e8740c6 554296 debian-policy_4.6.2.1.tar.xz
Checksums-Sha256:
 fc4f8728464f039ab2ff9063d28a9538e92cb68605d980ac608689306bfc80b6 2136 debian-policy_4.6.2.1.dsc
 0a69d1e25d821e6eb1e1773f4a8626ecdf2abf23ce50d0ba4e90208fd67052a3 554296 debian-policy_4.6.2.1.tar.xz
Files:
 9907e689604584693d5494d3133e71e0 2136 doc optional debian-policy_4.6.2.1.dsc
 d40f37ab7ab1b736b65844669a5baf01 554296 doc optional debian-policy_4.6.2.1.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmXZ48MACgkQaVt65L8G
YkCORQ/8D0vQa4AKBnKAmJd8QFrjbKMqSTphLlcq2kCaXnNEtTz0mtZ4YMQd+4lh
ce8J6/qOYarhkBSCvz//cb1WMDUXt4M9l0NoOMcw6rZHxzkUf315O8NLjktM0D52
/+HhdgMmE9IhzOqohNvmB/DiCogqfLQvKRswKdbr0FNIbeqv8CJAYZdatgoBIZVJ
zkpub9K3EM1tY3V5aRWi6rPj5QQIE0yMF1v+MP5aQc8cyTeE3YwPH1iAOJwgSUgE
CSBQqzYU1MgLVYipvVCp6at44Mpj32spUAOjXBxUGVfstR0lYzk6Q6y7nQwEb+rl
eFWkmSuY5ynkNAV1H4xvS4PVPFSHQU336cuUecc3c0TSynQ9fAi8tRfPgEW1UT87
mUmj8yjy8aSslv/Yhsb6/yULIJS0np01RXI4pBaTpu6CU2oVbtHJVW+Hcc4VKC7P
l5iN4CAV0wn8UqEXJPTd3TibtBlN0CbnfUIA6/ZxQq3CwI5OHp00PLPTHSoOEQe7
ZiurbnAAyI9Dlrn+lkUFMPF3ukeq6EaVelze/QMEB6BWP0ZAni7qWZKACaasuUkm
f/t+pWpVyZQx7CegSi2DGRnjsLD+wi2ylYu3GDvogrNR92I+kMgYOtX/PvSgJ904
FF3zt3K0ZNcsEkso456N/3Zcbp9/iwtxC6Pwtt2aLO5CdKj4QKU=
=9HMh
-----END PGP SIGNATURE-----