Hi,
I'd like to start a discussion about making the maintainer's preferences
regarding support for older Debian releases in source packages a bit
more explicit. In case this discussion garners interest, I'll draft a
more formal DEP.
## 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.
However this level of support is not clear to drive-by contributors.
Does `d/control` state `debhelper-compat (= 12)` because the maintainer
still supports stretch, or just because they forgot about it? Can
`dh-sequence-movetousr` be removed from this package, now that the
development of forky has started? Or does its maintainer routinely
backport to oldstable and thus that build dep is still necessary? Would
patches that fixed these issues be accepted or would they be wasted? A
drive-by contributor (or a large-scale refactoring program like the
janitor) has no way of knowing this in advance.
## Solution: basic idea
The package maintainer writes in `debian/source/support` (please
bikeshed this filename) which Debian releases they plan to support.
A missing or empty file indicates that "this package only targets
testing/unstable; backports will be built from slightly different
sources; feel free to submit patches that only deal with unstable". This
means that only maintainers that actually care about backports must add
a file, the others can ignore all this.
Example of a simple `d/s/support` file that I would use for my own packages:
```
debian/stable
debian/unstable
```
## 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).
Contact information can be added for certain specifiers (e.g.
"[email protected]").
### Examples
#### Example 1. "The package targets stable and oldstable."
```
debian/oldstable
debian/stable
debian/unstable
```
#### Example 2. "The package targets stable and oldstable; oldoldstable
is also targeted, but by another developer."
```
debian/oldoldstable [email protected]
debian/oldstable
debian/stable
debian/unstable
```
### Example 3. "The package needs to build on jessie because of reasons,
and we backport regularly to stable."
```
debian/8-jessie # Used by the VM at fakeexample.debian.net
debian/stable
debian/unstable
```
## Open questions:
* Is a more structured format needed?
* 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,
--
Gioele Barabucci
