Hi!

On Sun, 2024-12-15 at 09:27:06 +0100, Niels Thykier wrote:
> 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`).

Given the type of change, which seems rather safe and unobtrusive, and
with no concerns raised…

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

…I'm going to merge the changes I had queued implementing this,
targeting dpkg 1.22.12, which should get uploaded today/tomorrow.

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

I think these are pending, I guess once dpkg is in unstable, then
these can be filed/implemented.

>  * `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.

As mentioned in the thread, an MR was sent by Niels and has already
been merged.

Thanks,
Guillem

Reply via email to