Hello, On Mon, Aug 14 2017, Ian Jackson wrote:
> 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. This is what Sam wants. > 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. gbp already has very good support for this. I don't think it would be wise to add anything to dgit. > 3. origless workflow. You have a pristine-tar branch and want to > avoid having origs hanging around. I don't know of anyone who does this -- people don't usually think of pristine-tar as a tool for this purpose. > 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 ? pristine-tar already has logic to try to find the right git objects: you type `pristine-tar checkout foo_1.2.3.orig.tar.xz` and it finds it. However, you do need the pristine-tar branch to exist. I think the best dgit could do would be to fetch vcs-git which is likely to have the branch (perhaps there could be a switch to fetch that upon clone). dgit probably shouldn't be calling origtargz(1); I was recommending that as a recommendation to users. > 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). I think the best thing is for the user to put the right lines in d/gbp.conf and then use dgit gbp-build to do all this. >> >> 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... It sounded like Sam wants to use the .orig from his pristine-tar branch, not the archive. So we'd need to rm the orig that dgit downloads/not download it. -- Sean Whitton
signature.asc
Description: PGP signature
