Simon Richter <s...@debian.org> writes: > 1. upstream has an official .orig.tar.* file we can use
> In my opinion, we'd want to use this because we don't need to explain > how it was generated, and any signature from upstream can be used to > verify that we are shipping exactly their release. > I'm aware that there is disagreement over this point, and there is a > faction that would like us to rebuild upstream archives from git tags to > avoid problems like we had with xz-utils, but without an easy way for > users to verify that an archive corresponds to upstream git, we're > mainly introducing an explanation why signatures do not match and should > be disregarded. I think there are two cases here: upstream produces a tarball release as their official release artifact and produces a Git tag as a side effect or doesn't make a Git tag at all, or upstream produces both a tarball release and a Git tag and treats them both as first-class release artifacts. The first case is the weakest case for tag2upload until it has support for upstream tarballs. I think there are various ways to add that support that aren't too bad (git-lfs for instance) and don't require pristine-tar, but it's future work and they're not supported now. The second case seems fine with tag2upload? Particularly if upstream signs the Git tag. Instead of pointing to a possibly signed release tarball, the tag2upload tag points to a signed upstream Git tag. We get basically the same properties and avoid dealing with opaque upstream tarballs. Obviously this depends on what things are added to the release tarball, and there are a bunch of cases with gnulib, etc., where it's difficult to reproduce what upstream does during the release process for one reason or another. But there are a lot of upstreams for which this is not the case. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
