Niels Thykier
2024-12-15 08:30:01 UTC
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
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