Re: Upstreams with "official" tarballs differing from their git
Hi,
Le 2025-02-15 13:39, kpcyrd a écrit :
Diff between those two:
https://whatsrc.org/diff-right-trimmed/sha256:146d2d673358b7927d9a3c74e22b6b0e7f9a1aee2a4307afbe6ac07f12764130/sha256:599ff98cbab933a8b3640a084b12a5308a20795c192855ee454a8c1c16fa4dac
That divergence is reflected between the official upstream tarballs and
the tarballs that can be downloaded from their GitHub releases page.
There is a similar issue with Gradle where there are official "source
distributions" ZIPs [1] (generated by gradle as part of its build) and
not-really-that-much-less-official release tarballs [2] automatically
generated by GitHub. The divergence between both is shown at [3].
In the case of Gradle, as the official source ZIPs are lacking
documentation files that I think are important (e.g. LICENSE) I switched
to using GitHub tarballs, and will probably switch again to use uscan's
mode=git as it's simpler to configure and more reliable for large
projects that release often. That mode could end up being adopted by the
Java Team for all projects hosted on GitHub for that reason, and also
because it seems easier to convince upstream projects to sign their
release tags than to sign their release tarballs. In this specific case
however I also believe that the upstream project should fix their source
archives generation.
In the case of curl, I believe that for Debian using the official
tarball is fine. If I had to use their upstream git repo for Debian
packaging, I would probably write a small custom script that runs their
maketgz script and can be used in the watch file to regenerate
official-like "original" tarballs the same way as upstream.
Le 2025-02-15 12:10, Stéphane Glondu a écrit :
My approach to this specific problem would be to add to dune the
possibility to use some configuration file (or environment variables)
as input for the substitutions, instead of directly querying the VCS.
This configuration could then be set up as part of the Debian
packaging.
I think that this is a reasonable approach that would make the build a
lot less brittle, and that should be submitted upstream.
Cheers,
[1]: https://services.gradle.org/distributions/
[2]: https://github.com/gradle/gradle/tags
[3]:
https://salsa.debian.org/jpd/gradle/-/blob/287ae5c99790f266e242964321955f7c77f397df/debian/wip/delta-ghtar-gradlezip
--
Julien Plissonneau Duquène
Reply to: