> 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. 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. Although, as stated by Simon, git signatures are based on SHA-1 so not unbreakable anymore, but the point here is to illustrate the git-buildpackage feature. 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). - Otto PS. Massive thanks to Guido for maintaining git-buildpackage, it is a gem!
