[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Simpler git workflow for packaging with upstreamless repositories



gregor herrmann <gregoa@debian.org> writes:

> On Tue, 26 Nov 2024 20:49:44 +0100, Simon Josefsson wrote:
>
>> If you haven't made an upload, then wouldn't you have the tarball
>> locally while working on preparing the upload?
>> And if someone doesn't have the orig.tar.gz locally, then why would
>> anyone want to get it from a random git repository, rather than fetching
>> it from the Debian archive or from upstream's release page?  What is the
>> use-case here that am I missing?
>
> Person A creates a package, person B wants to work on it; use cases:
> teams in general, and sponsoring within or outside of teams.
>
> As person B I don't want to go hunting for a tarball and place it in
> the right place, I want gbp to re-create it from the pristine-tar
> branch.

That's not terribly convincing for a project-wide default, as
maintaining the tarball costs human time and storage space, and any
failures in pristine-tar handling takes time to debug too.

As person B above, I would personally prefer to chase down the trusted
intended tarball from upstream than to trust a random git repository for
it.  So the workflow you describe is not universal.

Few people seems to PGP sign their pristine-tar commits.  There are no
PGP-signed git tags on pristine-tar branch.  So there is no trust or
integrity protection of the pristine-tar tarball content, beyond git
HTTPS/SSH protection.

It is not uncommon to find pristine-tar branches with *.orig.tar.gz but
the corresponding (and uploaded) *.orig.tar.gz.asc file is not included.

Interestingly, I preferred use of pristine-tar branches before this
thread, but unless some more convincing argument appears I have changed
my opinion.

/Simon

Attachment: signature.asc
Description: PGP signature


Reply to: