Hello, On Fri 16 May 2025 at 11:52am +01, Ian Jackson wrote:
> Package: git-debpush > Version: 12.12 > > Consider a user who is used to using pristine-tar, either with dgit, > or with a dput-based upload flow. > > If they prepare a new upstream version, they may be surprised that > they use t2u, the .orig that ends up in the archive is not the one > that they imported into pristine-tar. > > I looked in git-debpush and it doesn't say explicitly how orig > tarballs will be created. It would be a good idea to be clearer about > that. (We perhaps don't want to mention pristine-tar in the main > text.) Strictly, it's an implementation detail of the combination of the service and the archive whether it even tries to fetch existing tarballs from the archive versus just generating new ones each time. But calling out that local tarballs you may have certainly aren't relevant in the manpage for git-debpush(1) is fine. > Also, it would be nice to detect this situation somehow. I don't > think we can *reliably* detect this since it's mostly a matter of > guessing the user's intent. > > I'm not sure, but I think maybe we could have a failed check in the > following circumstances: > > * We're not using a native source format. (For 1.0 do we already > check d/s/options for -sn before providing an upstream= in the > tag?) > > * The version number is -1 or -0.1. This is a fairly conservative > proxy for "will the t2u service need to generate a tarball". > > * There is pristine-tar data in the current tree for the current > upstream version. > > Sean, what do you think? > > Notes: > > This report prompted by some discussions in #1105766. > > I'm calling this "Severity: normal" because it's a surprising > behaviour that will probably annoy people if we don't at least take > some countermeasures or document it properly. Someone might want to maintain upstream tarballs in their local pristine-tar branch even if they know they won't reach the archive because they are using tag2upload. Then they'd have to --force every -1 upload. Not a huge deal but a disadvantage (currently you have to --force every experimental->unstable upload, which is similar). Otherwise, I think a check like this is a good idea, and I'll work on it. -- Sean Whitton
signature.asc
Description: PGP signature
