Gioele Barabucci:
Hi,
[...]
## Problem
Some maintainers like to keep their packages in a state that makes them
easy to backport to stable or older releases (without relying on
separate repositories or non-trivial branches). I find this stance
agreeable and it should perhaps even be encouraged.
[...]
Hi,
Thanks for starting this discussion.
I agree with the problem statement and I would like to see this being
machine readable as well.
Note that as prior art, the lintian-brush tool has a
debian/lintian-brush.conf file with a field for this piece of
information. Assuming this proposal goes through, I hope lintian-brush
will migrate to the new format.
## Solution: basic idea
The package maintainer writes in `debian/source/support` (please
bikeshed this filename) which Debian releases they plan to support.
[...]
My gut feeling is that a file like that would be the wrong place for
this. I would rather see this as a new field in `debian/control`. With
what is described so far, a space-separated field should be sufficient
in my book (Note: I disagree with the part of the format below as well.
The part I agree with fits in a space-separated list).
My main concern with adding new files is that files are not very
discoverable. As an example, editor support do not work very well with
recommending that you can do something in "some other file that you are
not currently viewing".
An alternative to this would be to have a
`debian/package-preferences.yaml` file for maintainer preferences or
some other package specific configuration, where this would be a single
field of that file. That way, it at least makes sense to invest in
editor support for the file as we can expect more fields to be added in
to it.
Editor support is easy to come by for `debian/control` (`debputy`) or
YAML files (for any editor with support for jsonschemastore.org via
https://salsa.debian.org/debian/debian-json-schemas - yes, the schemas
also work for YAML despite the naming)
## Solution: basic format spec
The file `debian/source/support` contains a list of supported releases,
one per line. Supported releases can be specified either via their
version number/nickname (e.g., "11-bullseye") or via time-relative
nicknames (e.g., "oldoldstable").
Release specifiers must be vendored (e.g., "debian/12-bookworm") to
allow the coexistence of support information for Debian-derivatives (if
the Debian maintainer so wishes).
I am fine up to this point. A bit unsure why we want the version number
and the nick name. I would personally prefer `debian/bookworm`,
`debian/12` or `debian/oldstable` over `debian/12-bookworm` +
`debian/oldstable`.
But it is not a hill I am willing to die on, so if people strongly for
using `12-bookworm` over `12` or `bookworm` then fine by me.
Contact information can be added for certain specifiers (e.g. "lts-
[email protected]").
Maybe it is just me being unlucky, but I have yet to have been in a
situation, where I had this kind of work flow where the primary
maintainer maintains stable compatibility but does not actually do the
upload. So for me this feels theoretical and not very useful in practice.
That being said, if this is really valuable, then I am even more
convinced that we should **not** add it to an unstructured file.
In YAML we could have:
```
supported-targets:
- dist: debian/unstable
- dist: debian/stable
- dist: ubuntu/foo-lts
contact: "[email protected]"
```
and we would **not** need to write parser for yet another Debian
specific format that looks like but is not quite the same as all the
other files in `debian/*`.
[...]
On the topic of the content, I think from a tooling PoV only the oldest
support target matters in most cases. As a human reader as well, if I
see `jessie`, I will not propose any modernisation beyond what jessie
can support.
In that sense `unstable` seems a bit superfluous, but I suppose there
might be a case for "LTS-only, stop bothering me about stuff that is
only relevant for future releases".
## Open questions:
* Is a more structured format needed?
I would say yes.
* Should all supported releases be specified (e.g., "11, 12, 13,
unstable"), or should specifying a certain version (e.g., "11")
implicitly express support for all other release up to unstable?
Regards,
The latter is how it would play out in practice for all the purposes I
have in mind. Maybe recommend oldest plus newest if we want to support
the case where an LTS team forks the package. That way they can say
"this fork will never reach unstable, so stop nagging us about stuff
that is only relevant for future proofing in newer releases" (as
mentioned above).
So in summary:
1) I agree with the problem and that it is worth solving.
2) I disagree with the concrete solution, preferring us to use an
existing format. Preferably, `debian/control` if we agree that
the contact information is irrelevant. A new YAML file otherwise.
Best regards,
Niels
