Otto Kekäläinen <o...@debian.org> writes: >> No objections to have this kind of capability, but I still strongly >> believe that importing tar archives is highly suboptimal and directly >> branching off the upstream git repository is an highly superior workflow >> and should be used as much as possible. >> >> This being said, I maintain some packages which are released by the >> upstream maintainers only as tar archives (because OpenBSD). > > Also some projects release tarballs with extra additions that are not > in the same git, or they strip away directories/files that are in git, > but are irrelevant for users. If upstreams do that, then their intent > is that downstreams are better off consuming the tarballs.
Indeed. Some projects also release both variants -- for example 'libntlm' and 'oath-toolkit' upstream releases both traditional autoconf tarballs and minimal source-only 'git archive' style tarballs. > This is not a problem though, We can have the best of both, as > git-buildpackage supports dual import from both upstream git and > tarball to maximize supply chain auditability. > > You can see this in action in e.g. > https://salsa.debian.org/mariadb-team/mariadb-server/-/network/debian%2Flatest?extended_sha1=f134a53ffcaad16eabedb30809837d5ee8170bc8&filter_ref=1 > The upstream branch 11.4 and tag mariadb-11.4.3 has the upstream git > release contents, while the branch upstream/latest and tag > upstream/11.4.3 shows the contents of the release tarball. The diff > between these two branches shows how the upstream tarball differs from > the upstream git commit at the time. The git side can be verified with > git tag signature, and the tarball side is verified by tarball > signature (thanks to also pristine-tar being used). This > upstream/latest was then merged on debian/latest, which has git tags > signed by Debian maintainer. ... > If you want to see the details, see gbp.conf in the package > (https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/gbp.conf). That setup sounds nice! What is your workflow to import a new upstream release? I see the watch file still points to the tarball: https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/watch Would it be possible to extend the debian/watch syntax to be able to express both a tarball and upstream git branch? Then 'gbp import-orig' would import both the tarball and sync git, after performing PGP tarball verification and Git branch signature verification. I suppose you are doing that manually somehow now? /Simon
signature.asc
Description: PGP signature
