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.)

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.

Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmgoUT8ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQMnTD/9i0+fw5dyYV08rV/x+Tk7v gUH6Pv239o9da6pdQjnYxD+/+oqPj31yOGhTNAo5hOMS40QfuuwCAwSPipqtnOYA WQt5w2ZluNRMeicNlUl0PN3BqNIM9MPWn1V2WTrM69R9DulijAV5NicH5mQpiRpU MbBt32rtW3A1dDuVfJgnP2PteskBkm38oPEX64hlj/hsg72drj9ZBukYsqhOoCpk fjtNO3+hymbcVwn1/U5bbg7hVknZxTpU+SV2hoXSOY6VswdTEHFxrYc0wwuofk29 Izovpv/g9whQPVJr0+YdJZOFwzLKOPk6LOyJNO00yJmpBx6tuKbK7M1/CwZQ4kzs kgi507c9ZtVW9bVC+ddUdSdLLUB879FctOS+s8olbP2fiJOwXvh0tiGHshRMM80A oCPBgUFacj7znEwlxI0+Vf3TA5Uc1+WUY2ktRC24twVNvtgJA1vao2PN9bvMG/Aq BzzPBPz2dOdcgAM143sSoUcuBKKFN0oEj93NpYcDxelrHhAgdw7daUSLpL4LE52t SU9cmiFho5nqAYqeLKbi516+h5a42ZeRaSmCqPCYCe6TPlHbPOO9F+6Eln81ax14 aFTOK7xsn/1eEn8oc7lS4wteX4uIfa+sHVkXRQ1/x0aEGxdC8B1PE1gM8Zm741O3 FESOsF3jFqqYt23yWUMRSw==Jwmc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Sean Whitton writes ("Bug#1105862: git-debpush and detecting intent to use pristine-tar"):

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.

Yes. Also that git-debpush doesn't attempt to transfer pristine-tar information via git, which is a thing the user might expect it to do.

Also, it would be nice to detect this situation somehow.

...

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).

I think people who use pristine-tar are (overwhelmingly) doing in
accordance with the doctrine that Debian should base its work on, and redistribute, upstream tarballs. That's what pristine-tar is *for*.
So I think complaining in this situation will almost always be
correct.

The only concern I have is: what happens if you stop using (wanting to
use) pristine-tar. Does gbp tooling maintain the branch if it exists?
I mean: would you have to do something to stop it doing that, or pass
--force every time?

Otherwise, I think a check like this is a good idea, and I'll work on
it.

Thanks,
Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat 17 May 2025 at 12:05pm +01, Ian Jackson wrote:

Yes. Also that git-debpush doesn't attempt to transfer pristine-tar information via git, which is a thing the user might expect it to do.

Hmm, yes, I guess they might expect that. I was thinking that
pristine-tar is too weird and we are trying to be non-Debian-weird, but
new users won't be thinking in tha tway.

I think people who use pristine-tar are (overwhelmingly) doing in
accordance with the doctrine that Debian should base its work on, and redistribute, upstream tarballs. That's what pristine-tar is *for*.
So I think complaining in this situation will almost always be
correct.

Okay.

The only concern I have is: what happens if you stop using (wanting to
use) pristine-tar. Does gbp tooling maintain the branch if it exists?
I mean: would you have to do something to stop it doing that, or pass
--force every time?

You would have to disable pristine-tar in your gbp.conf but that's not
very difficult.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmgpxysZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQK24D/45iFVdA94Nj90biLCxmhEn k5w4G+ERZvK65PFhF3Rp9wwG3aZMhjC//m/ESA5KAO/fWk/smH9fAGBefZRpJw/U pp97sAKYjYUVfoamawt+pt0GoUODyIOC07Oc+HHRsQ1qA0KGdv5dyWOLtSqpki6a d59hFwGH6f4baeKx115kt6q8qidc9hRveMB+SSaakGDarsuPXAVMkeQ3wcVv8fMJ RHesibnOse4HvYS5IcT1YHhWc8iqda1KfsS8ozJWBhU5BgDcQ1G/nU4pBVjo/Akw KFJCK+9wmA+zTKke7NDP/Yxcfzi2+mLePAZVRmdySMVrf7gAp3cEdqrBUqMuc+up f4VoCc+u/gJq0PspOTNufJHeTY424AmDes2t/NltDqEq4q6vVitp60dSJCISQMqP 98SD4fAhahNA8IcqaLe0ETQtq6FSEY96BfOtp1cT7IRJ+AOQr/HW1BCtc6zdhDT1 J5cj+IpREclCj9q8tNTJ7GNC4LwIRROgf+JHWQ/LOKnEUbE8v6EuPyqok+4cIg8M YGsz8tPAbZRZTxTv83/NBk8inXi4wkzPCiPjV3MS6u89yqXWCF7PeB8PST/0xP/o Zq3UQwt71lQupJxelTI+RU+QQVJI0Wz3P3Oh+XtYi9m8wOqfcbyFSWBwIsjwyBE6 PvAfsTN5Jpteca3Fg5cbmw==VrFN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us