On 24/01/26 04:16, Simon Richter wrote:
However this level of support is not clear to drive-by contributors.
Even drive-by contributors, seldom as they are, should read
debian/README.source.
`d/README.source` has already been suggested as a possible location for
this information, but I think that the other two options (namely, a file
under `d/source/` or a field in `d/control`) are both better than
`d/README.source`.
Let me explain. `d/README.source` is already used as a free-form way to
convey information about the source. It's not machine readable nor is
its content standardized. And that is fine. Now the point of this
proposal is to have a _standardized_ and _machine readable_ way to
express support for old Debian releases. Having this information in
`d/README.source` would mean mixing it with the existing free-form data.
That's a parsing nightmare that I would avoid.
And, BTW, we also don't put the package format in `d/README.source`, nor
the URL where the packaging Git repo lives. These and similar
machine-readable packaging-related pieces of information are governed by
precise specs and are stored in other files.
Does `d/control` state `debhelper-compat (= 12)` because the
maintainer still supports stretch, or just because they forgot about it?
There is a third option, which goes for most of my packages: because it
doesn't matter, as they don't connect to any interface that isn't stable
yet -- so updating the compat level is just extra work and archive churn
for no good reason.
Why would it be archive churn?
Accepting a patch that updates dh's compat level to 13 (or any other
patch in general) does not require a maintainer to create a new release
right away. Patches/MRs can be accumulated (`bts 1234 tags pending`) and
a new release created whenever the maintainer sees fit.
Regards,
--
Gioele Barabucci
