(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.