Re: Simpler git workflow for packaging with upstreamless repositories
On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson wrote:
> I have never understood what value there is in duplicating the uploaded
> tarball in the git repository.
The actual cost of storing the pristine tarball is quite small. For
example:
commit 91c7ab39337da63371b4814bef2b2aaf85a9e37c (origin/pristine-tar, pristine-tar)
Author: Theodore Ts'o <tytso@mit.edu>
Date: Mon May 20 23:12:54 2024 -0400
pristine-tar data for e2fsprogs_1.47.1.orig.tar.gz
e2fsprogs_1.47.1.orig.tar.gz.asc | 11 +++++++++++
e2fsprogs_1.47.1.orig.tar.gz.delta | Bin 0 -> 63961 bytes
e2fsprogs_1.47.1.orig.tar.gz.id | 1 +
3 files changed, 12 insertions(+)
Compare if I had to keep all of the old release tarballs around:
9.5M e2fsprogs-1.47.1.tar.gz
The reason why I find pristine-tar *super* valuable is because it
stashes the signed tarball and tarball in a highly efficient way, and
which can be easily backed up by just doing a "git push" to github /
git.kernel.org / salsa. I can then just kick off a git-buildpackage
in a super-convenient way, so the tooling is quite mature and
convenient for development velocity.
I could imagine an alternate way of generating data for
git-buildpackage, by replacing the pristine with something that stores
the detached GPG signature, and then a shell script which generates
the orig.tar.gz, for example at [1]. But now we'd have third-party
users who want to rebuild the debian packages from source executing an
arbitrary shell script found in the git repository to generate the
orig.tar.gz file, which would be a security nightmare. Pristine-tar
is a much better from that perspective.
[1] https://github.com/tytso/e2fsprogs/blob/master/util/gen-git-tarball
Cheers,
- Ted
Reply to: