Ian Jackson <[email protected]> writes: > You're right, we don't have a feature that puts just orig tarballs > somewhere else. We only have--build-products-dir (which I think is > analagous to gbp's export-dir) which puts *everything* there.
Oh! I think I see my confusion: I thought this didn't work but it actually does. If build-products-dir is set, dgit does use that directory as an *input* as well as an *output* get the orig.tar.gz file from that directory. This is not the semantics of git-buildpackage as I recall (it's been a few years), but it sort of makes sense. The logging is a little weird in a way that makes that somewhat inobvious: dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building libnet-ldapapi-perl using existing ./libnet-ldapapi-perl_3.0.7.orig.tar.gz I assume this is because dgit has already changed working directories to the build-products-dir. But I guess I never actually tried it; sorry about that! > Marc, do you set both export-dir and tarball-dir ? We (dgit) should > probably align our behaviour with gbp's and there will be corner cases > to consider. A common pattern with git-buildpackage if you don't want to use pristine-tar (or that those of us who were using it before pristine-tar existed always did) is to have a ../tarballs directory where you keep all the upstream tarballs for all your various Debian packages, and then you set build-dir to ../build-dir and tarballs-dir to ../tarballs. That way, you can always rm * in ../build-dir after you finish uploading without losing anything of value. Marc of course should weigh in on what he was expecting, but that may be what he was hoping for. I don't really care (I can just run origtargz to get the tarball again in places where I use pristine-tar), so now that I know build-products-dir works, I'm mostly happy. The missing piece is telling origtargz to always use that directory as well, but that's not a dgit problem. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
