Re: Git Packaging: Native source formats
Hi,
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstream, as well as to reduce upload time.
Saving space and bandwidth when only changing the packaging was a nice
bonus, but the main reason we use upstream tarballs verbatim is
verifiability (which you also mention later on).
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the same.
> You don't need to synthesize a separate upstream tarball.
FWIW, I don't think that this is much of an impediment. "git archive"
exists and is deterministic, so if we can also compress the archive in a
reproducible way, then the "upstream" tarball will be identical.
> It seems particularly attractive when upstream doesn't produce tarballs
> and instead does their development in git.
Lots of upstream projects use git and still produce tarballs for releases.
What we don't have a good workflow for is upstream software that does not
have distinct releases, and frankly, the technical aspect of that is the
smallest part of the problem.
We already have lots of software in the archive that upstream will not
support, essentially telling users to update to the most recent version.
Unless the package maintainer is willing to support the users themselves in
that case, I would say that including that software in a stable release is
not beneficial for users, and making it easier for Debian contributors to
package this software is not going to improve things.
Not everything needs to be packaged, and even less needs to be included in
releases. As a maintainer, it is a completely valid technical decision to
file an RC bug on your own package "this should not go into the release",
and the stable release managers will not ask you to close the bug so the
package can be included.
We need to work together with upstream to identify a state of the software
that we feel comfortable supporting (also together with upstream) for the
lifetime of a Debian release.
No change in the packaging workflow will make this part any easier.
> It's clear that we value integrity of upstream source. That is we
> want to make it easy for people to start from some upstream source
> that is trusted because upstream has produced it and audit just our
> changes.
> One way to do this is with an upstream tarball and a diff (or set of
> diffs or a debian directory).
> But if we're thinking that people will be working in Git, another way
> to do this is to merge in a signed upstream git tag. Then you can
> perform a diff against that git tag.
That requires speaking a complex protocol in which a program that is not
expecting malicious input repeatedly parses and decompresses untrusted data
before it is able to verify any signatures. It also assumes availability of
unfiltered Internet services over which cryptographic signatures can be
exchanged.
Simon
Reply to: