Re: [RFC] General Resolution to deploy tag2upload
Simon McVittie <smcv@debian.org> writes:
> On Wed, 12 Jun 2024 at 16:04:34 -0000, Marco d'Itri wrote:
>>> Is your position here that if your upstream releases source tarballs
>>> that intentionally differ from what's in git (notably this is true for
>>> Autotools `make dist`), then any Good™ maintainer must generate their
>>> own .orig.tar.* from upstream git and use those in the upload,
>>> disregarding upstream's source tarball entirely?
>> It is mine, and this is what I have been doing for a long time for all
>> my packages.
> If there is consensus that devref is lagging behind best-practice and
> actually this is fine (or preferable, or should-be-required), perhaps
> someone who advocates this model could propose a replacement for devref
> §6.8.8?
As one of the people who used to advocate for the current devref guidance
to be best practices, I think we should relax the guidance somewhat here.
I don't think it's wrong to package for Debian that way, and there are
some traceability advantages to being able to reuse the upstream tarball
signature if there is one, but there are also significant disadvantages.
It's a complicated tradeoff with good arguments for both approaches.
To some extent the best choice today depends on upstream's maintenance
practices. To take an obvious example, if an upstream treated signed Git
tags as their foundational release artifact and tarballs as an annoying
byproduct they produce only because people insist on them (or just let
GitHub autogenerate from tags), I don't think following the devref
guidance and putting more weight on the upstream tarballs than upstream
does would be best practice.
In my personal opinion, tag2upload is more compelling for packages where
the upstream maintainer treats Git tags as their primary release artifact,
and less compelling for packages where the upstream maintainer views Git
as a possibly incomplete implementation detail of their workflow and
signed tarball releases as the only supported release artifact. I would
pick and choose when to use it based on those sorts of factors. That's
one of the reasons, in my mind, why use of it would be entirely optional.
It's an extension of Debian packaging practices to a Git-first world, and
therefore makes the most sense when upstream has adopted a Git-first
development approach.
(Although, that said, it's still very tempting to move source package
construction off of local machines and into a buildd-style clean and
reproducible environment. That security and reliability advantage may
make it worth it to me to break the provenance link with upstream signed
tarballs, even though I still think it's a shame to have to do that.
Hopefully more upstreams will adopt signed Git tags as well, even if they
want to continue making signed tarball releases.)
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: