Hi,

just a question which I hope was not addressed before in this long
thread I have no chance to follow completely. If it was just answered
simply point me to the archive (or alternatively the tag2uplod doc is
its described there): 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. How is the problem to get the
original tarball solved in tag2upload?

Kind regards
Andreas.

--
https://fam-tille.de

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

On Fri, 14 Jun 2024 at 12:26:50 +0100, Ian Jackson wrote:

Note however: right now you can't do a source-only upload of a new
upstream version, and tag2upload only supports source-only uploads.
So this situation generally won't arise: someone will have had to
upload the orig.tar.gz the old way.

I think I must be misunderstanding you, because as far as I can see,
I do source-only uploads of new upstream versions rather frequently
(for example flatpak_1.14.8-1 was a source-only upload, for which
I think I used dgit). To achieve that, I need to arrange to have a
suitable orig.tar.* where dpkg-buildpackage or dgit are going to find it (currently achieved with uscan and/or pristine-tar), which I recognise
is non-trivial to achieve for tag2upload.

You can't currently do a source-only upload of a completely new *package*,
or of a new upstream release that bumps SONAME or otherwise adds new
binary packages, because the ftp team requires a binary upload[1] for
anything that will go into the NEW queue. Is that what you're thinking of?

But most new upstream releases (at least for relatively mature packages)
don't break backwards compatibility and don't need to go through NEW.

smcv

[1] technically the upload needs at least one binary package, but
presumably the ftp team usually prefer uploaders to follow the spirit
of the rules as well as the letter, and the spirit of the rule is that
they want to see a comprehensive set of binary packages for at least
one architecture so that Lintian can flag any obvious mis-packaging

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

Andreas Tille writes ("How is the original tarball obtained in tag2upload"):

just a question which I hope was not addressed before in this long
thread I have no chance to follow completely. If it was just answered
simply point me to the archive (or alternatively the tag2uplod doc is
its described there): 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. How is the problem to get the
original tarball solved in tag2upload?

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.

Note however: right now you can't do a source-only upload of a new
upstream version, and tag2upload only supports source-only uploads.
So this situation generally won't arise: someone will have had to
upload the orig.tar.gz the old way.

This isn't brilliant. If source-only uploads of new upstream versions
become supported, it would probably be worth t2u supporting
pristine-tar for origs.

Ian.

--
Ian Jackson <[email protected]> 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)

Simon McVittie writes ("Re: How is the original tarball obtained in tag2upload"):

You can't currently do a source-only upload of a completely new *package*,
or of a new upstream release that bumps SONAME or otherwise adds new
binary packages, because the ftp team requires a binary upload[1] for anything that will go into the NEW queue. Is that what you're thinking of?

Yes.

But most new upstream releases (at least for relatively mature packages) don't break backwards compatibility and don't need to go through NEW.

Right. I think this means that supporting pristine-tar would be
useful right away. As I say, we don't have that yet.

Ian.

--
Ian Jackson <[email protected]> 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)

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.

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

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCZmyz6wAKCRDbymUJHySO bOuKAP9H9jIp0ipdmI4wc58JahlyS4YYVnBf9tBvl5jIrwr79gD+IBunUYg+/iOz 1U0NfrUU2NBOhx74AiUdZBfvcYg+wQY=
=PmRV
-----END PGP SIGNATURE-----

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

Phil Morrell <[email protected]> writes:

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.

I also have questions about whether pristine-tar is a viable long-term technical design. We have to maintain a lot of changes in underlying
tools to make it work, and my understanding is that we've had failure
modes in the past where a tarball is reproducible with pristine-tar at the time, but if you try to reproduce it five years later with the current set
of tools in unstable, that may fail. The problem that it is trying to
solve is technically very difficult and also not prioritized by various upstreams, which puts it on rather shaky ground.

If we want to continue supporting verbatim upstream tarballs as the basis
for Debian packaging (which I think we clearly do for at least some
packages), I think it would be better to think about how to introduce the actual tarball as an artifact using git-lfs or some similar approach,
rather than attempt to reconstruct it from Git. The tools simply don't
support doing the latter, and pristine-tar has to go to heroic efforts to
try to make this work.

This of course has all of the known problems with potentially malicious upstream tarballs that differ from Git tags, but there are ways to detect
some of those problems while still basing the packaging on the actual
tarball as released. And it would let us reuse the upstream signature on
the tarball, which is useful in some cases to provide a bit of additional provenance and tracing.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

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

Phil Morrell <[email protected]> writes:

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.

What I think is missing is for tag2upload to be able to use and/or
verify upstream's PGP signed git-archive tarball. The git archive
format is known to not be stable nor reproducible over time, and there
are upstream who PGP sign the the git-archive tarball.

I'm still a supporter of tag2upload on social grounds, but on technical
and security grounds there are several things that leaves me unimpressed
- but we are good at improving technical things over time. FWIW, I
found Didier's "debconf22-94-lightning-talks.webm" talk to offer a
better approach, which is more consistent with reproducible artifacts:

https://meetings-archive.debian.net/pub/debian-meetings/2022/DebConf22/

As far as I can tell, tag2upload will make reproducible source artifacts
harder to achieve (git-archive is run as a SaaS, and may not match what upstream publish) and verify (any PGP signatures from upstream on the git-archive is thrown away), but in Didier's approach both properties
seems native and built in from the start.

/Simon

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

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

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZm080hQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFommaAP9yr/UtMZdwviLOVUma4ifh7I1TNTqZ nmU86DptKOzFFQD/VcMFgIN+70Jb9HnTZqVrw+nsBEd2UpPq4fC+sXIAjQU=9+c+
-----END PGP SIGNATURE-----

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------n6AsFOSQ5I0aWNoWRcqhTy8W
Content-Type: multipart/alternative;
boundary="------------a63dpTlVbkCLL0aWJoYKGFLK"

--------------a63dpTlVbkCLL0aWJoYKGFLK
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTUuMDYuMjQgMDk6MDMsIFNpbW9uIEpvc2Vmc3NvbiB3cm90ZToNCj4gQXMgZmFyIGFz IEkgY2FuIHRlbGwsIHRhZzJ1cGxvYWQgd2lsbCBtYWtlIHJlcHJvZHVjaWJsZSBzb3VyY2Ug YXJ0aWZhY3RzDQo+IGhhcmRlciB0byBhY2hpZXZlIChnaXQtYXJjaGl2ZSBpcyBydW4gYXMg YSBTYWFTLCBhbmQgbWF5IG5vdCBtYXRjaCB3aGF0DQo+IHVwc3RyZWFtIHB1Ymxpc2gpIGFu ZCB2ZXJpZnkgKGFueSBQR1Agc2lnbmF0dXJlcyBmcm9tIHVwc3RyZWFtIG9uIHRoZQ0KPiBn aXQtYXJjaGl2ZSBpcyB0aHJvd24gYXdheSksIGJ1dCBpbiBEaWRpZXIncyBhcHByb2FjaCBi b3RoIHByb3BlcnRpZXMNCj4gc2VlbXMgbmF0aXZlIGFuZCBidWlsdCBpbiBmcm9tIHRoZSBz dGFydC4NCg0KWW91J3JlIGFzc3VtaW5nIHRoYXQgVXBzdHJlYW0gYWN0dWFsbHkgcHVibGlz aGVzIHRhcmJhbGxzLiBUaGF0IA0KYXNzdW1wdGlvbiBiZWNvbWVzIG1vcmUgYW5kIG1vcmUg dW5saWtlbHksIHRoZXNlIGRheXMuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBVcHN0cmVhbSBo YXMgcHJlc3VtYWJseSB0YWdnZWQgdGhlaXIgcmVsZWFzZTsgYSB0YWcgDQp3aGljaCB0aGVu IHdhcyB1c2VkIHRvIGJ1aWxkIHRoZWlyIHRhcmJhbGwsIGlmIGl0IGV4aXN0cy4gVGhleSBt aWdodCANCmV2ZW4gaGF2ZSBzaWduZWQgdGhhdCB0YWcuIDotUA0KDQpTbyB3aHkgd291bGQg d2Ugd2FudCB0byB1c2UgdGhlIHRhcmJhbGwgaW5zdGVhZCBvZiB0aGUgdGFnPw0KDQoNCldo ZW4gSSB3b3JrIHdpdGggZ2l0IChpLmUuIGFsbCB0aGUgdGltZSwgdGhlc2UgZGF5cykgSSB3 YW50IHRoZSBzb3VyY2VzIA0KdG8gYmUgaW4gZ2l0LiBJIHdhbnQgImdpdCBibGFtZSIgdG8g d29yay4gSSB3YW50IHRvIGJlIHN1cmUgdGhhdCB3aGF0J3MgDQppbiBteSBnaXQgdHJlZSBj b3JyZXNwb25kcyB0byB3aGF0IHRoZSBidWlsZCBzeXN0ZW0gc2F3LiBBbmQgc28gb24uIEkg ZG8gDQoqbm90KiB3YW50IHRvIG1hbnVhbGx5IGNoZWNrIHRoYXQgdGhlIFVwc3RyZWFtIHRh cmJhbGwgY29ycmVzcG9uZHMgdG8gDQp0aGUgVXBzdHJlYW0gdGFnLCBtdWNoIGxlc3MgYmVp bmcgZm9yY2VkIHRvIGRvIHNvIGJlY2F1c2UgRGViaWFuIGNob29zZXMgDQp0byB1c2UgdGhl IGxhdHRlci4NCg0KVGhhdCB1cHN0cmVhbSB0YXJiYWxsIG1pZ2h0IHdlbGwgYmUgc2lnbmVk LCBidXQgSSBrbm93IG5vdGhpbmcgYWJvdXQgaG93IA0KY2xlYW4gaXQgaXMgYW5kIHdoZXRo ZXIgaXQgY29udGFpbnMgYW55IGFydGlmYWN0cyB0aGF0IGFyZW4ndCBpbiBnaXQgYnV0IA0K aGF2ZSBiZWVuIGFkZGVkIGJ5IHNvbWUgcmFuZG9tIGJ1aWxkIHN5c3RlbSAobm90IHRvIHNw ZWFrIG9mIG1hbGljaW91cyANCmFnZW5jeSwgYXMgaW4gdGhlIHh6IGNvbXByb21pc2UpLg0K DQpUbyBtZSB0aGUgc291cmNlIHRhcmJhbGwgaXMgYSBuZWNlc3NhcnkgZXZpbCwgcmVxdWly ZWQgYnkgb3VyIGJ1aWxkZXJzIA0KYmVjYXVzZSB0aGV5IGhhdmVuJ3QgeWV0IGxlYXJuZWQg dG8gc2ltcGx5ICJnaXQgY2xvbmUiIHRoZSBEZWJpYW4gYnJhbmNoIA0KZnJvbSBTYWxzYSwg cHVzaCB0byBhbiBhcHBlbmQtb25seSBnaXQgc3RvcmUgZm9yIGFyY2hpdmluZyBhbmQgDQpy ZXByb2R1Y2liaWxpdHksIGFuZCBiZSBkb25lIHdpdGggaXQuDQoNClRvIG1lLCB0YWcydXBs b2FkIGlzIG9uZSBzdGVwIHRvd2FyZHMgdGhhdCBnb2FsLCBmcmFua2x5IHdlIGNhbid0IGdl dCANCnRoZXJlIGZhc3QgZW5vdWdoIElNSE8uIE9uZSB0aGluZyB3ZSBkZWZpbml0ZWx5IGRv ICpub3QqIG5lZWQgb24gdGhlIHdheSANCnRoZXJlIGlzIGluY3JlYXNlZCByZWxpYW5jZSBv biB1cHN0cmVhbSB0YXJiYWxscywgd2hldGhlciBpbXBsaWVkIG9yIA0KZXhwbGljaXQuDQoN Ci0tIA0KLS0gcmVnYXJkcw0KLS0gDQotLSBNYXR0aGlhcyBVcmxpY2hzDQoNCg== --------------a63dpTlVbkCLL0aWJoYKGFLK
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 15.06.24 09:03, Simon Josefsson
wrote:<br>
</div>
<blockquote type="cite" cite="mid:[email protected]">
<pre>As far as I can tell, tag2upload will make reproducible source artifacts
harder to achieve (git-archive is run as a SaaS, and may not match what upstream publish) and verify (any PGP signatures from upstream on the git-archive is thrown away), but in Didier's approach both properties
seems native and built in from the start.</pre>
</blockquote>
<p>You're assuming that Upstream actually publishes tarballs. That
assumption becomes more and more unlikely, these days.<br>
</p>
<p>On the other hand, Upstream has presumably tagged their release;
a tag which then was used to build their tarball, if it exists.
They might even have signed that tag. :-P</p>
<p>So why would we want to use the tarball instead of the tag?</p>
<p><br>
</p>
<p>When I work with git (i.e. all the time, these days) I want the
sources to be in git. I want "git blame" to work. I want to be
sure that what's in my git tree corresponds to what the build
system saw. And so on. I do *not* want to manually check that the
Upstream tarball corresponds to the Upstream tag, much less being
forced to do so because Debian chooses to use the latter.<br>
</p>
<p>That upstream tarball might well be signed, but I know nothing
about how clean it is and whether it contains any artifacts that
aren't in git but have been added by some random build system (not
to speak of malicious agency, as in the xz compromise).</p>
<p>To me the source tarball is a necessary evil, required by our
builders because they haven't yet learned to simply "git clone"
the Debian branch from Salsa, push to an append-only git store for
archiving and reproducibility, and be done with it.</p>
<p>To me, tag2upload is one step towards that goal, frankly we can't
get there fast enough IMHO. One thing we definitely do *not* need
on the way there is increased reliance on upstream tarballs,
whether implied or explicit.<br>
</p>
<pre class="moz-signature" cols="72">--
-- regards
--
-- Matthias Urlichs</pre>
</body>
</html>

--------------a63dpTlVbkCLL0aWJoYKGFLK--

--------------n6AsFOSQ5I0aWNoWRcqhTy8W--

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

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmZvS9gFAwAAAAAACgkQcs+OXiW0wpNh yg//VyQFwOkrnhjA+ZUqOR46oAi5CfEnJoM6fxt6PeuZdXEE6tZB26cWBzK7UN4DNXOrpeNtRwkj Je1WdIwLY+phPg20OUXoKARzMDen1+4nUcyHDarehZIIKw5kPZHD3Y9DzGQmvckt8U7XG6IJW6V/ Qn4h81mb8DH3ebdx6Qag8x8JdtJfggJjhN6Ly5S6TD2xWkD5BG5O8jRZ7haN4TaKATVEHquyqvue YPUCEy0n8KEWRkZjKxV8iKHRgALwu5IUPMr+VzS9jRfhKVlf08ZvySK810T4ZxTHpiRAR4mpcYdz tbbyuBlwd0X6DzQRcBz2Zx1Fb6KfqZduTrlV+TY1tonQcNEaUhf0FivR3MFY7ycDPafWRTnUk4hQ BEixgI8Ol4zTvFoJ5boj9UK9e2uahafIvSEUf9uZHp2o0hwQuQ8GFrBRECFJveKgE/VSVyEBGrAR 2Dg3X+FrNrqCR9c3Jjg/LHBRdJk1lXybujT9oBcJ49mIEZ9Tglar/bZ/OlViy1WE3Ftjh4F8NN/q 74mqVJdg28HBuu0Iu92iNIBiA47PgxbVfxtI+ekxizP3JUkYu+t9FGERX9vObXXtFiUP5vUvC1B+ tCu8uSpz/SLDgV/FcBZWUdJMN5YoSW6xJ37Z83m8TAfyVUGPM7KXKM2U5rIUnoDKdxgEdCRlv6Kv f8k=
=eVCx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05

So why would we want to use the tarball instead of the tag?

Because it's easier to download? It is certainly faster.

I think you assume that 100% of the software is identical to the things you work on. Which is probably untrue.


--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

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

On Fri, Jun 14, 2024 at 02:35:24PM -0700, Russ Allbery wrote:

Phil Morrell <[email protected]> writes:

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.

I also have questions about whether pristine-tar is a viable long-term technical design.

It's not. It *could* be viable, pending implementation details, if we
could get the archive to verify checksums on uncompressed tarballs, i.e.
dak would effectively ignore the compression, and then only verify the
contents of the uncompressed tarball. The plain tar format is simple
enough that is easy to produce, and even in the cases where it's not
(like tarballs produced with a weird tar), a binary diff would be
ridiculously small because the metadata embedded in the tarball is very
small compared to the actual data.

But that would open yet another can of worms, not to speak of the amount
of tools that would need changing to support storing and verifying
hashses on the uncompressed content tarballs.

We have to maintain a lot of changes in underlying
tools to make it work, and my understanding is that we've had failure
modes in the past where a tarball is reproducible with pristine-tar at the time, but if you try to reproduce it five years later with the current set
of tools in unstable, that may fail. The problem that it is trying to
solve is technically very difficult and also not prioritized by various upstreams, which puts it on rather shaky ground.

If we want to continue supporting verbatim upstream tarballs as the basis
for Debian packaging (which I think we clearly do for at least some packages), I think it would be better to think about how to introduce the actual tarball as an artifact using git-lfs or some similar approach,
rather than attempt to reconstruct it from Git.

That already exists: pristine-lfs.

The tools simply don't support doing the latter, and pristine-tar has
to go to heroic efforts to try to make this work.

This of course has all of the known problems with potentially malicious upstream tarballs that differ from Git tags, but there are ways to detect some of those problems while still basing the packaging on the actual
tarball as released. And it would let us reuse the upstream signature on
the tarball, which is useful in some cases to provide a bit of additional provenance and tracing.

That too.

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

iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmZwJqAACgkQ/A2xu81G C97KdBAAg/4Dza+jiVYk8OeWRev0RCyXnOItUjdvN/5e9wD8RJDEW+hqRuJrGJi7 sTAAubZ0upN6putfaqtLawLHHCkrIfhMQC06NVkbK3iMXucEV/P7W7fYiwmWmP7Q DVwH3qpbfATjEy735+9Jea9JN1bHfZVt5nxuipIqqBadIsKIWbDs5IoC6++CaeLp VTr7rfOqkWiRPYPJr++Qu3seK3nz1KAvYc+WgUAK+BItqGM/KM+vD+iygZdDGrPp chtri3ubYtdUHyZ0cZ2xhL9WFLqku+cKPBiOUO2YHJkLFtBFYZSnIo2t5N02oyI3 pl+CbV2MXidM9rGjUX/beUHx3Kposc8hFxuW1+DJKwJO4NJWxukBKk4Dwh5fA2hV uqUqvxhS8m9Qb8PcDmByI4Cr6jYv4R0h1sju5Q+sIeA4ijUhiS1tgYJptuEE3Pmd BJuoPJlBeDKTjweEksrsv9JVVzL+CuLRL3S62zlLnez/sir1ymhe44hLmCxPS1YO xMwc214PXg9zXhFECrml7WKzrTRWULV/qJBtTMYgXyRXpMPAF5TMkJNj6oDKKZYm 5VsLiZB6ueGg4qEJwpsYsJE6vyzh59HsPnfLjPuIG92TLHleSH4E5A0nSMEfNWfn TWvP3T64OuFI7oXspMKkzi1d5B62rCq40NHghB4kWGSxJHC9SMk=
=k5EF
-----END PGP SIGNATURE-----

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

Hello,

On Sun 16 Jun 2024 at 11:45pm +02, Salvo Tomaselli wrote:

So why would we want to use the tarball instead of the tag?

Because it's easier to download? It is certainly faster.

I think you assume that 100% of the software is identical to the things you work on. Which is probably untrue.

Right, this sort of thing is why tag2upload is intended to be an
additional option for uploads, never mandatory, because it doesn't suit
every package, upstream or Debian maintainer.

It does suit many packages better than tarball-based workflows do, but
not all of them.

--
Sean Whitton

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