Hi,

Historically, if you omitted `Priority` and `Section` from your
package, `dpkg` would warn and use `-` or `unknown` as placeholder
when it absolutely needed a value for these fields in the `.dsc` and
the `.changes` file. The resulting `.deb` would omit the field.

We would like to change this behavior such that `dpkg` provides
defaults for these fields. That is, if the fields are omitted from
`debian/control`, you get `Priority: optional` and `Section: unknown`
as default in all artifacts (`.dsc`, `.changes`, and in the `.deb`).

Benefits of this change and the approach being:

 1. The vast majority of future maintainers will no longer need to
    learn about the `Priority` field. Concretely, Only ~300 (0.5%)
    of the packages in Debian testing main uses a different
    `Priority`. This makes it a low hanging fruit in reducing mental
    load for people learning packaging for the 99.5% case down the
    line as there will be one line less worth of field/boilerplate
    to know about in the average case. Tutorials and guides can move
    the `Priority` field from "mandatory" to "special-case" section,
    etc.

    The default for `Section` would always be `unknown` rather than a
    mix of `-` and `unknown` in `.dsc` and `.changes` vs. absent in
    the `.deb`. This has no direct benefits to the packager, only to
    consumers of the produced artifacts. `Section` would still
    "de-facto" be mandatory, since `unknown` is never the right
    choice. This change is mostly to keep the code aligned with the
    `Priority` in `dpkg` and replace the `-` special-case (from `.dsc`
    and `.changes`) with `unknown`.

 2. The omission only applies to `debian/control` and the build
    process. The produced artifacts will have the fields, so anything
    working on the produced artifacts will be unaffected. This
    includes archive metadata such as `Packages` files. In other
    words, only developer tools reading `debian/control` can be
    affected by this (and tools that read the `-` in the `.dsc` and
    `.changes`, but we suspect there are none other than possibly dak).

 3. All existing packages have these fields and will continue to have
    them until the maintainer removes them (with `Priority` being the
    only "removable" field at this point). Therefore, the transition
    will happen slowly when the maintainers and their personal tooling
    is ready. Though, maintainers of backports should keep this change
    in mind, since the `dpkg` version will be relevant for the new
    behavior and `dpkg` in stable/oldstable will not have the correct
    default for `Priority` at the beginning.

    Additionally, maintainers can choose to keep the `Priority` field
    in `debian/control` if they so desire at no loss of functionality.

In other words, this should be a safe change that only has benefits by
making the default simpler.

# The affected tools

Here are the tools that we are aware of that is or might be affected.

 * `dpkg` (such as `dpkg-source`, `dpkg-genchanges`, and
   `dpkg-gencontrol`) will need to be updated to implement
   the change.

 * Maintainer tools such as `lintian`, `debputy [lint|lsp server]`,
   etc. should stop warning about missing `Priority` field for
   unstable. Most other maintainer facing tools should not care at
   all, since the `Priority` field is mostly for d-i.

   With `Section` being de facto mandatory, nothing major changes here
   for that field.

 * `dak` and other archive processing may need tweaking as `-` will
   disappear (we can assume all uploads will come from a `dpkg`
   version that has these features). Concretely, any special casing
   of `-` for `Priority` will be redundant, and any special case
   for `-` should apply equally to `unknown` for `Section`.

   Though, our understanding is that `dak` likely only uses the cases
   where `dpkg` used `unknown` consistently (such the `Package-List`
   in the `.dsc`). Accordingly, we suspect it might not need any
   changes other than a review to be sure.

Let us know if you are aware of any tools that might be adversely
affected. Notably, let us know if any thing here would be critically
affected that would prevent roll out in `dpkg`.

# Tools we expect to be unaffected or only positively affected

 * Any tool that uses `Section` and `Priority` from the Debian archive
   metadata (`Packages`). We are not aware of any case where the
   archive has allowed them to be missing and this change will
   no affect that.

 * Any tool that reads `Section` and `Priority` from `.deb` files.
   The fields will now always be there rather than theoretically
   optional.


Best regards,
Guillem and Niels

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to