Proposal: Optional `Priority: optional` and changed `Section` fall-back

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

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE9ecZmu9eXGflVYc/dA1oiINl0okFAmdektsACgkQdA1oiINl
0olGhgf/ZFMUJRslJsKH3fd+IdEqMfdo4RzK6pBwq0tLxHWaX5OvLi+S5GnRPxQ/
3z75JTI1jfjMsAlCTLAZ5IdC+8bboAqPgFePIc36OOYftxaSB8VlkMtNy3GakBkY
y87xkGNqNXhxxd/VzPaSArMwS3oWKmHSnhv23CFmxAMzh0Qex1GetDZAiRs3Rv3b
7WUnrsTgwlIG1K9nTRU4ywFPIckDAeHTsnpHa2FiNxFBz14nII4eFOn6B7N5m+/U
EOXLVFmyEMYNMJrig20Fwdmelw3XyYCnmPD86B/rr8opk0vcXOwHnLU+M3NHoc26
HqgtdGRynH2EL0ojBTCN4sHcyjsDGg==
=9ihR
-----END PGP SIGNATURE-----