On Fri, Jun 14, 2024 at 12:26:50PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("How is the original tarball obtained in tag2upload"):
> > In many teams we keep the metadata about the
> > orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases
> > this works flawlessly but I've observed some exceptions and read about
> > potential problems with pristine-tar.
>
> Firstly, if there is an orig in the archive, the t2u robot will use
> that. Failing that, it will use "git-deborig" which will call
> "git-archive". Currently there isn't any support for pristine-tar;
> that would be possible in principle.(risking doing design on debian-vote, but it's a bit late for that) It's been my impression [citation needed] that pristine-tar/lfs still exists mainly out of inertia and simple tooling around it that makes it more of a why not. If we're gaining a mostly git-native upload workflow out of this, I think it would be wise to second-guess if this support is even needed in tag2upload. You're already using the archive to obtain the orig.tar where available, which neuters one of pristine-tar's purposes: to get everything needed to build past releases from just a git clone [1]. New upstream versions *for likely users of tag2upload*, I believe the git-archive generated tarball would be a sufficient incidental artifact to be uploaded - making tag2upload the authoritative one-off source instead of (presumably) upstream's forge generator. -- emorrp1 [1]: speaking of which, and the answer might be "just learn to use dgit", but it'd nice to have whatever mechanism is doing this built into e.g. `gbp buildpackage` in the same way pristine-tar currently is.
signature.asc
Description: PGP signature
