(Sam, do say if you want to be dropped from this design discussion.)
Sean Whitton writes ("Bug#871909: dgit gbp-build fails if user specifies
--git-builder"):
> On Sun, Aug 13 2017, Ian Jackson wrote:
> > I think the right direction might be for there to be a way to tell
> > dgit that you are wanting to use this workflow, but perhaps indeed
> > running origtargz and the dgit sbuild will DTRT.
>
> So: dgit doesn't download the orig iff both (a) a config value is set;
> and (b) a pristine-tar branch (local or remote) exists.
There are three situations I think:
1. fetch. There is a pristine-tar branch available somewhere. You
want to avoid downloading the .orig, and instead use origtargz
from the pristine-tar branch.
2. push. You have a local pristine-tar branch and are making a new
upstream version. You do not have the .orig as a file. You want
to synthesize the .orig for the upload.
3. origless workflow. You have a pristine-tar branch and want to
avoid having origs hanging around.
For fetch, the main difficulty seems to me to be finding or guessing
which pristine-tar git objects are supposed to produce the .orig.
Note that dgit doesn't need to be entirely sure it has the right
objects, because it has the checksum of the intented .orig. If the
attempt to construct it from a pristine-tar produces a different file,
dgit would spot this (and could fail, or fall back to downloading the
file from the archive).
We can't expect the pristine-tar branch to be in git.dgit (currently
it's not even possible to upload it there). Perhaps dgit could hope
for a vcs-git header and then guess that the pristine-tar branch there
might be useful.
I'm not very familiar with pristine-tar etc. Does each tarball
correspond to one commit ? Is it easy to find the commit
corresponding to a previous tarball ? Is the commit self-contained
(that is, does it reference as parents or whatever any other commits
or objects needed) or does one need other branches ?
[1] assuming that origtargz is safe to run at all on a possibly-wrong
candidate.
As a workaround, the user can git clone or git fetch the relevant
branch(es) or tag(s) themselves, and run origtargz to regenerate the
.orig. dgit will then use it rather than downloading it again.
For push, the orig generation is something that will happen before
build. (Since build builds the source as well as the binaries.)
So it's part of the various dgit build methods, which is where this
bug report comes in.
I'm not really convinced by --git-builder= as a way for the user to
request this. I think you could just set a config option, as you
suggest, and then dgit would find the local pristine-tar branch and
use it, probably by invoking gbp or something.
It has to be a local pristine-tar branch, I think. This can only
be relevant for a new upstream version (since for an existing upstream
version, the orig ought to be have been procured, one way or another,
by fetch).
A fully origless workflow (ie one where the user does not see the
.orig or need to care about it) is rather harder. In practice I think
there would have to be a .orig cache or something, because dgit needs
to use dpkg-source (and therefore the actual .orig) for quilt fixup
and for constructing new trees during fetch and for verifying things
during push and so on. Regenerating the .orig each time would be far
too slow.
> >> Though I guess you have to rm the orig that dgit downloads.
> >
> > I don't see why that would be needed. If dgit clone or dgit fetch
> > gets an orig, then surely it will be the same as the pristine-tar one.
>
> If there is already an orig.tar present than origtargz(1) won't
> overwrite it.
That's surely right. The existing .orig will be correct and there is
no need to do anything to it. If you were to rm it, origtargz would
simply regenerate the very same file (or, if it didn't, things would
break). I think I must be missing something...
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
