Simon Richter writes ("tag2upload, reproducible .orig and dfsg repacks"):
> 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,
This is already there.
Firstly, everything I'm about to say applies only to a new upstream
version upload. For an existing upstream version, the existing .orig
from the archive is obtained and reused, so no orig construction takes
place.
Secondsly, there is only currently one supported way to generate an
orig: git-deborig aka git-archive. So the protocol in this area is
fairly simple, and the possible extension to support other orig
generation modes is not described in the document.
The relevant protocol elements are the `upstream=` and `upstream-tag=`
keywords in the tag2upload tag metadata. tag2upload(5) says:
| The orig tarball will be generated with "git archive", as invoked
| by "git deborig".
If we were to support pristine-tar we would include that information
in the tag. Probably, we'd specify the pristine-tar branch commitid,
and a ref to obtain it from (maybe the pristine-tar brancy). But, I
haven't designed this in detail.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
