Hello, On Fri 03 Jan 2020 at 08:43PM -08, Russ Allbery wrote:
> Russ Allbery <r...@debian.org> 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 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. > @@ -1066,7 +1066,7 @@ The field can consist of exactly one of the following > three items: > - A space separated list of keywords described below. These keywords > must always contain a forward slash, which sets them apart from the > other possible values of ``Rules-Requires-Root``. When this list > - is provided, the builder must provide a `gain root command` (as > + is provided, the builder must provide a "gain root command" (as > defined in :ref:`debian/rules and Rules-Requires-Root > <s-debianrules-gainrootapi>`) *or* pretend that the value was set > to ``binary-targets``, and both the builder and the package's > @@ -1128,10 +1128,9 @@ In addition to the keywords defined in the next > section, each tool or > package may define keywords within a namespace named after that tool > or package. The package or tool is considered to own that namespace. > > -A tool may use the `gain root command` to do something under > -(fake)root if and only if the tool defines an appropriate keyword in > -its namespace, and the package lists that keyword in > -``Rules-Requires-Root``. > +A tool is permitted to use the "gain root command" to do something under > +(fake)root if and only if the tool defines an appropriate keyword in its > +namespace, and the package lists that keyword in ``Rules-Requires-Root``. > > All tools must ignore keywords under namespaces they do not know or > own. A tool may emit a warning, or abort with an error, if it finds > diff --git a/policy/ch-customized-programs.rst > b/policy/ch-customized-programs.rst > index 747df56..bf8dabb 100644 > --- a/policy/ch-customized-programs.rst > +++ b/policy/ch-customized-programs.rst > @@ -139,11 +139,8 @@ web servers and web applications in the Debian system. > > 3. Access to images > > - It is recommended that images for a package be stored in > - ``/usr/share/images/package`` and may be referred to through an alias > - ``/images/`` as > - > - :: > + Images for a package should be stored in ``/usr/share/images/package`` > + and referred to through an alias ``/images/`` as:: > > http://localhost/images/package/filename > > diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst > index b466304..f823e79 100644 > --- a/policy/ch-docs.rst > +++ b/policy/ch-docs.rst > @@ -141,7 +141,7 @@ separately, as package-doc for example, it may be > installed under either > that path or into the documentation directory for the separate > documentation package (``/usr/share/doc/package-doc`` in this example). > However, installing the documentation into the documentation directory > -of the main package is preferred since it is independent of the > +of the main package is encouraged since it is independent of the > packaging method and will be easier for users to find. > > Any separate package providing documentation must still install standard > @@ -157,9 +157,10 @@ documentation should be installed elsewhere, such as > under > ``/usr/share/package/``, and then included via symbolic links in > ``/usr/share/doc/package``. > > -``/usr/share/doc/package`` may be a symbolic link to another directory > -in ``/usr/share/doc`` only if the two packages both come from the same > -source and the first package Depends on the second. [#]_ > +``/usr/share/doc/package`` is permitted to be a symbolic link to another > +directory in ``/usr/share/doc`` only if the two packages both come from > +the same source and the first package Depends on the second. Otherwise, > +``/usr/share/doc/package`` must not be a symbolic link. [#]_ > > .. _s12.4: > > @@ -201,9 +202,10 @@ A copy of the file which will be installed in > ``/usr/share/doc/package/copyright`` should be in ``debian/copyright`` > in the source package. > > -``/usr/share/doc/package`` may be a symbolic link to another directory > -in ``/usr/share/doc`` only if the two packages both come from the same > -source and the first package Depends on the second. These rules are > +``/usr/share/doc/package`` is permitted be a symbolic link to another > +directory in ``/usr/share/doc`` only if the two packages both come from > +the same source and the first package Depends on the second. Otherwise, > +``/usr/share/doc/package`` must not be a symbolic link. These rules are > important because ``copyright`` files must be extractable by mechanical > means. > > @@ -229,9 +231,8 @@ Machine-readable copyright information > > A specification for a standard, machine-readable format for > ``debian/copyright`` files is maintained as part of the debian-policy > -package. This document may be found in the ``copyright-format`` files in > -the debian-policy package. It is also available from the Debian web > -mirrors at > +package. This document is in the ``copyright-format`` files in the > +debian-policy package. It is also available from the Debian web mirrors at > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/. > > Use of this format is optional. > diff --git a/policy/ch-files.rst b/policy/ch-files.rst > index 06816ac..b34c183 100644 > --- a/policy/ch-files.rst > +++ b/policy/ch-files.rst > @@ -18,7 +18,7 @@ which program will have to be renamed. If a consensus > cannot be reached, > *both* programs must be renamed. > > To support merged-\ ``/usr`` systems, packages must not install files in > -both ``/path`` and ``/usr/path``. For example, a package may not install > +both ``/path`` and ``/usr/path``. For example, a package must not install > both ``/bin/example`` and ``/usr/bin/example``. > > If a file is moved between ``/path`` and ``/usr/path`` in revisions of a > @@ -409,8 +409,8 @@ default version will be part of the package distribution, > and must not > be modified by the maintainer scripts during installation (or at any > other time). > > -In order to ensure that local changes are preserved correctly, no > -package may contain or make hard links to conffiles. [#]_ > +In order to ensure that local changes are preserved correctly, packages > +must not contain or make hard links to conffiles. [#]_ > > The other way to do it is via the maintainer scripts. In this case, the > configuration file must not be listed as a ``conffile`` and must not be > @@ -582,8 +582,8 @@ Permissions and owners > The rules in this section are guidelines for general use. If necessary > you may deviate from the details below. However, if you do so you must > make sure that what is done is secure and you should try to be as > -consistent as possible with the rest of the system. You should probably > -also discuss it on ``debian-devel`` first. > +consistent as possible with the rest of the system. You are also > +encouraged to discuss it on ``debian-devel`` first. > > Files should be owned by ``root:root``, and made writable only by the > owner and universally readable (and executable, if appropriate), that is > diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst > index 707f2d4..709aabf 100644 > --- a/policy/ch-maintainerscripts.rst > +++ b/policy/ch-maintainerscripts.rst > @@ -184,7 +184,7 @@ The ``postrm`` script may be called in the following ways: > removed or replaced. The package whose ``postrm`` is being called > may have previously been deconfigured and only be "Unpacked", at > which point subsequent package changes do not consider its > - dependencies. Therefore, all ``postrm`` actions may only rely on > + dependencies. Therefore, all ``postrm`` actions must only rely on > essential packages and must gracefully skip any actions that require > the package's dependencies if those dependencies are unavailable. > [#]_ > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 4551196..db7fde3 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -42,14 +42,14 @@ Debian Policy. The following exceptions to the FHS apply: > and ``/usr/lib{,32}`` is amended, permitting files to instead be > installed to ``/lib/triplet`` and ``/usr/lib/triplet``, where > ``triplet`` is the value returned by ``dpkg-architecture > -qDEB_HOST_MULTIARCH`` for the architecture of the > - package. Packages may *not* install files to any triplet path other > + package. Packages must not install files to any triplet path other > than the one matching the architecture of that package; for > instance, an ``Architecture: amd64`` package containing 32-bit x86 > - libraries may not install these libraries to > + libraries must not install these libraries to > ``/usr/lib/i386-linux-gnu``. [#]_ > > - No package for a 64 bit architecture may install files in > - ``/usr/lib64/`` or in a subdirectory of it. > + Packages 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 > @@ -440,7 +440,7 @@ Instead, they should be placed in a file in > ``/etc/default``, which > typically will have the same base name as the ``init.d`` script. This > extra file should be sourced by the script when the script runs. It must > contain only variable settings and comments in POSIX.1-2017 ``sh`` format. It > -may either be a ``conffile`` or a configuration file maintained by the > +must either be a ``conffile`` or a configuration file maintained by the > package maintainer scripts. See :ref:`s-config-files` for > more details. > > @@ -488,8 +488,8 @@ archive or manually create or remove the symbolic links > in maintainer > scripts; you must use the ``update-rc.d`` program instead. (The former > will fail if an alternative method of maintaining runlevel information > 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 is permitted to do so.) > > To get the default behavior for your package, put in your ``postinst`` > script:: > @@ -521,10 +521,10 @@ package's init script would not start the service until > the local > system administrator changed this to ``DISABLED=no``, or similar. The > problem with this approach was that it hides from the init system > whether or not the daemon should actually be started, which leads to > -inconsistent and confusing behavior: ``service <package> start`` may > +inconsistent and confusing behavior: ``service <package> start`` could > return success but not start the service; services with a dependency > on this service will be started even though the service isn't running; > -and init system status commands may incorrectly claim that the service > +and init system status commands could incorrectly claim that the service > was started. > > Note that if your package changes runlevels or priority, you may have to > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 1211e3e..915d00d 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -143,7 +143,7 @@ Binary Dependencies - ``Depends``, ``Recommends``, > ``Suggests``, ``Enhances``, ` > > ---------------------------------------------------------------------------------------------- > > Packages can declare in their control file that they have certain > -relationships to other packages - for example, that they may not be > +relationships to other packages - for example, that they cannot be > installed at the same time as certain other packages, and/or that they > depend on the presence of others. > > @@ -379,7 +379,7 @@ problem. ``Breaks`` should be used > - when two packages provide the same file and will continue to do so, > > - in conjunction with ``Provides`` when only one package providing a > - given virtual facility may be unpacked at a time (see > + given virtual facility can be unpacked at a time (see > :ref:`s-virtual`), > > - in other cases where one must prevent simultaneous installation of > diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst > index e3db6c1..0fc2f8a 100644 > --- a/policy/ch-scope.rst > +++ b/policy/ch-scope.rst > @@ -20,7 +20,7 @@ interface to the package management system with which the > developers > must be conversant. [#]_ > > This manual cannot and does not prohibit every possible bug or > -undesirable behaviour. The fact that something is not forbidden by > +undesirable behaviour. The fact that something is not prohibited by > Debian policy does not mean that it is not a bug, let alone that it is > desirable. Questions not covered by policy should be evaluated on > their merits. > @@ -31,21 +31,41 @@ part of Debian policy itself. > The appendices to this manual are not necessarily normative, either. > Please see :doc:`ap-pkg-scope` for more information. > > -In the normative part of this manual, the words *must*, *should* and > -*may*, and the adjectives *required*, *recommended* and *optional*, are > -used to distinguish the significance of the various guidelines in this > -policy document. Packages that do not conform to the guidelines denoted > -by *must* (or *required*) will generally not be considered acceptable > -for the Debian distribution. Non-conformance with guidelines denoted by > -*should* (or *recommended*) will generally be considered a bug, but will > -not necessarily render a package unsuitable for distribution. Guidelines > -denoted by *may* (or *optional*) are truly optional and adherence is > -left to the maintainer's discretion. > - > -These classifications are roughly equivalent to the bug severities > -*serious* (for *must* or *required* directive violations), *minor*, > -*normal* or *important* (for *should* or *recommended* directive > -violations) and *wishlist* (for *optional* items). [#]_ > +In the normative part of this manual, the following terms are used to > +describe the importance of each statement: [#]_ > + > +* The terms *must* and *must not*, and the adjectives *required* and > + *prohibited*, denote strong requirements. Packages that do not conform > + to these requirements will generally not be considered acceptable for > + the Debian distribution. These statements correspond to the *critical*, > + *grave*, and *serious* bug severities (normally serious). They are > + collectively called *Policy requirements*. > + > +* The terms *should* and *should not*, and the adjective *recommended*, > + denote best practices. Non-conformance with these guidelines will > + generally be considered a bug, but will not necessarily render a package > + unsuitable for distribution. These statements correspond to bug > + severities of *important*, *normal*, and *minor*. They are collectively > + called *Policy recommendations*. > + > +* The adjectives *encouraged* and *discouraged* denote places where Policy > + offers advice to maintainers, but maintainers are free to follow or not > + follow that advice. Non-conformance with this advice is normally not > + considered a bug; if a bug seems worthwhile, normally it would have a > + severity of *wishlist*. These statements are collectively calld *Policy > + advice*. > + > +* The term *may* and the adjective *optional* are used to clarify cases > + where it may otherwise appear that Policy is specifying a requirement or > + recommendation. In those cases, these words describe decisions that are > + truly optional and at the maintainer's discretion. > + > +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. > > 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 > @@ -57,6 +77,31 @@ 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 > + one of the following requirements: > + > + Standard interfaces > + The material presented represents an interface to the packaging > + system that is mandated for use, and is used by, a significant > + number of packages, and therefore should not be changed without > + peer review. Package maintainers can then rely on this interface > + not changing, and the package management software authors need to > + ensure compatibility with this interface definition. (Control > + file and changelog file formats are examples.) > + > + Chosen Convention > + If there are a number of technically viable choices that can be > + made, but one needs to select one of these options for > + inter-operability. The version number format is one example. > + > + Please note that these are not mutually exclusive; selected > + conventions often become parts of standard interfaces. > + > +.. [#] > + Compare RFC 2119. Note, however, that these words are used in a > + different way in this document. > + > .. _s1.2: > > New versions of this document > @@ -189,33 +234,8 @@ UTF-8 > useful property of having ASCII as a subset, so any text encoded in > ASCII is trivially also valid UTF-8. > > -.. [#] > - Informally, the criteria used for inclusion is that the material meet > - one of the following requirements: > - > - Standard interfaces > - The material presented represents an interface to the packaging > - system that is mandated for use, and is used by, a significant > - number of packages, and therefore should not be changed without > - peer review. Package maintainers can then rely on this interface > - not changing, and the package management software authors need to > - ensure compatibility with this interface definition. (Control > - file and changelog file formats are examples.) > - > - Chosen Convention > - If there are a number of technically viable choices that can be > - made, but one needs to select one of these options for > - inter-operability. The version number format is one example. > - > - Please note that these are not mutually exclusive; selected > - conventions often become parts of standard interfaces. > - > Translations > ------------ > > When translations of this document into languages other than English > disagree with the English text, the English text takes precedence. > - > -.. [#] > - Compare RFC 2119. Note, however, that these words are used in a > - different way in this document. > diff --git a/policy/ch-sharedlibs.rst b/policy/ch-sharedlibs.rst > index 6cb98b2..69b79d3 100644 > --- a/policy/ch-sharedlibs.rst > +++ b/policy/ch-sharedlibs.rst > @@ -89,7 +89,7 @@ be unnecessarily difficult because of file conflicts with > the old > version of the package. When in doubt, always split shared library > packages so that each binary package installs a single shared library. > > -Every time the shared library ABI changes in a way that may break > +Every time the shared library ABI changes in a way that could break > binaries linked against older versions of the shared library, the > ``SONAME`` of the library and the corresponding name for the binary > package containing the runtime shared library should change. Normally, > @@ -322,7 +322,7 @@ shared library with only a ``shlibs`` file, the generated > dependency > will require a version of the shared library equal to or newer than the > version of the last ABI change. This generates unnecessarily restrictive > dependencies compared to ``symbols`` files if none of the symbols used > -by the package have changed. This, in turn, may make upgrades needlessly > +by the package have changed. This, in turn, could make upgrades needlessly > complex and unnecessarily restrict use of the package on systems with > older versions of the shared libraries. > > @@ -470,9 +470,9 @@ dependency version (for ``shlibs``) files. But special > care should be > taken to update dependency versions when the behavior of a public symbol > changes. This is easy to neglect, since there is no automated method of > determining such changes, but failing to update versions in this case > -may result in binary packages with too-weak dependencies that will fail > +could result in binary packages with too-weak dependencies that will fail > at runtime, possibly in ways that can cause security vulnerabilities. If > -the package maintainer believes that a symbol behavior change may have > +the package maintainer believes that a symbol behavior change could have > occurred but isn't sure, it's safer to update the version rather than > leave it unmodified. This may result in unnecessarily strict > dependencies, but it ensures that packages whose dependencies are > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index ee46db9..bd79828 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -251,7 +251,7 @@ source files in a package, as far as is reasonably > possible. [#]_ > Restrictions on objects in source packages > ------------------------------------------ > > -The source package may not contain any hard links, [#]_ device special > +The source package must not contain any hard links, [#]_ device special > files, sockets or setuid or setgid files.. [#]_ > > .. _s-debianrules: > @@ -307,7 +307,7 @@ commands it invokes options that cause them to produce > verbose output. > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, no required targets may attempt > +For packages in the main archive, required targets must not attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. > > @@ -659,14 +659,15 @@ substitutions, including the format of > ``debian/substvars``. > > .. _s-debianwatch: > > -Optional upstream source location: ``debian/watch`` > ---------------------------------------------------- > +Upstream source location: ``debian/watch`` > +------------------------------------------ > > -This is an optional, recommended configuration file for the ``uscan`` > -utility which defines how to automatically scan ftp or http sites for > -newly available updates of the package. This is also used by some Debian > -QA tools to help with quality control and maintenance of the > -distribution as a whole. > +This is a configuration file for the ``uscan`` utility which defines how > +to automatically scan ftp or http sites for newly available updates of the > +package. This is also used by some Debian QA tools to help with quality > +control and maintenance of the distribution as a whole. If the upstream > +source of the package is available via a mechaism that ``uscan`` > +understands, including this configuration file is recommended. > > If the upstream maintainer of the software provides OpenPGP signatures > for new releases, including the information required for ``uscan`` to > @@ -798,14 +799,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``. > > Vendor-specific patch series > ---------------------------- > diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst > index 06db3b5..09f58f8 100644 > --- a/policy/upgrading-checklist.rst > +++ b/policy/upgrading-checklist.rst > @@ -44,6 +44,10 @@ Version 4.5.0 > > Unreleased. > > +9.1.1 > + No package is allowed to install files in ``/usr/lib64/``. Previously, > + this prohibition only applied to packages for 64-bit architectures. > + > 9.3.2 > Packages that include system services should include ``systemd`` > service units to start or stop those services. Seconded, except for the debian/missing-sources change, but including the may->can change Sam suggested. -- Sean Whitton
signature.asc
Description: PGP signature
