Hi Niels,
thank you for your review of the proposal.
On 23/01/26 18:57, Niels Thykier wrote:
Gioele Barabucci:
## 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.
I agree with the problem statement and I would like to see this being
machine readable as well.
That's the only thing that matters. The technical implementation is
secondary.
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.
Thank you (and Chris on IRC) for pointing it out. I was not aware of it.
For the record here is what lintian-brush.conf(5) says:
compat-release = RELEASE
compat-release specifies the oldest release that the package aims to
be compatible with. lintian-brush will not make any changes that
require packages or features not present in this release. Supported
values are Debian and Ubuntu code names as well as aliases
("testing", "experimental", "stable", "unstable"). Version numbers
are currently not supported. The default compat release is "stable".
So the differences are that the proposal being discussed here...:
1) supports expressing more than one release;
2) differentiates between debian/ and <derivative>/ releases.
3) defaults to unstable.
"compat-release" is a nice name for this field.
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`.
[...]
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".
I understand your main point; a field in the source stanza of
`d/control` would also be OK for me. Additional info could be stuffed
into <foo> tags, like we do for profiles.
But, as an aside, if this ever get implemented, I would suggest creators
of tooling to _not_ suggest or hint (or nag) about adding such a field.
Most packages and maintainers are better served by its absence and a
sane default matching the current practices.
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`.
I'd go for "number is compulsory, nickname is optional". This allows the
lines to be easily sorted using `sort -V` without any external info
about which nickname maps to which release date.
(I'd like to use the same format for DEP-14 branch names, but that's
another story.)
And personally, I have been around Debian since Potato, but I have a
hard time remembering whether Lenny is older than Wheezy and I confuse
Squeeze and Stretch constantly (a draft of this had "9-squeeze"). Am I
the only one?
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.
* 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?
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).
That was the rational behind having an explicit list of releases. Thanks
for putting it in clear words.
In a more structured format, one could have both "oldest-supported =
debian/jessie" (what everybody who care about this will use) and
"newest-supported = debian/bookworm" (used only in the rare case you
described), removing the need to explicitly lists everything between.
The even more rare (only hypothetical?) case of wanting to skip releases
would not be supported by that semantics.
Regards,
--
Gioele Barabucci
