Hi,
We basically have three cases:
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.
In this case, I'd like a tag2upload service to have a mechanism to
ensure the upload will use the correct file -- i.e. a mismatch in
pristine-tar settings will not cause the file to be rebuilt differently
and subsequently uploaded because there is no verification step between
constructing the source package and uploading it.
2. upstream has no official release, but a git tag we can use
Here, it obviously makes sense to use git-archive.
3. upstream needs to be repacked for dfsg reasons
So far, I believe this has no good representation in git, and the
packages that do this basically generate a dfsg orig.tar.* file and
reimport this into git -- which is pretty much the least ideal
situation, because we have no links to the upstream repo.
For 1. and 2., what I'd like to kind of see as part of the interface to
a tag2upload service is a way to explicitly specify what kind of .orig
archive should be constructed, and this needs to become a condition for
actually uploading, so the magic tag containing maintainer intent would
explicitly say "the .orig archive needs to have this sha256sum" for the
pristine-tar case, and "the .orig archive needs to have a git extended
pax header containing this sha1sum/sha256sum" for the second.
I have no good idea for dfsg repacks so far.
Simon
