Russ Allbery writes ("Re: Bug#1128520: please implement
dgit.default.tarball-dir"):
> 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.
Yes.
> This is not the semantics of git-buildpackage as I recall (it's
> been a few years), but it sort of makes sense.
I set dgit.default.build-products-dir to ../bpd soon after I
implemented the feature (after someone else's request) and haven't
looked back.
Sadly git-deborig and origtargz don't use it.
> 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!
In fact dgit is running dpkg-source in a secret hidden working area it
creates inside your .git directory. I don't think there is any way to
improve this output from dpkg-source.
> 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.
Oh there are *three* configurable directories! I'm concerned that the
number of available corner cases is rising exponentially. Maybe we
can satisfy most people by understanding their use cases.
Separating out the orig tarballs makes sense for the reason you give.
If we allowed you to do that then you could indeed always safely nuke
your bpd.
> 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.
The difficult part isn't teaching origtargz to do it. The difficult
part is deciding on a common location where tools like this get their
information.
origtargz is in devscripts which doesn't really have a common
configuration scheme and I doubt trying to institute one there would
be either a good idea, or fun.
git-deborig is in src:dgit nowadays, so we *can* do what we feel best,
but what is best?
dgit uses git for its configuration and this has a lot of really
compelling advantages. You get host-global, user-global and
tree-local config settings. You get a taxonomy, a set of file formats,
can easily add a coherent commnad-line override facility. You get the
config file reader and only have to interpret the values. The data
model is pretty good.
I think it's a shame that gbp doesn't read git-buildpackage.whatever
things from git config.
Maybe we should invent a debian.* namespace for git config options and
attempt to run an internal registry for it. git-deborig could use
that and dgit could fall back to debian.* if it doesn't find
dgit-distroy.debian.build-products-dir and
dgit.default.build-products-dir.
Marc Haber writes ("Re: Bug#1128520: please implement
dgit.default.tarball-dir"):
> Sadly, at the moment I don't remember which other software insists
> on the tarball being in ..
We could institute a Debian-wide default for orig tarballs by putting
it in devscripts and making the tools there honour it. It would want
some negotiation with the gbp maintainers but it doesn't seem
impossible.
> ยน I'd love to have export-dir templatable (for example, writing build
> artifacts to ../build-area-<package>-<version>-<arch>), but gbp upstream
> was not excited about that.
I think we should prioritise getting all these different programs to
agree and if that means the functionality is more restricted then
that's better.
Personally I wouldn't object to such a scheme in principle but I am
already foreseeing difficulties with it: for example, dgit
doesn't always *know* what the architecture is.
We could probably define a substitution syntax, and some variables,
and tell programs that don't want to implement it (or a particular
substitution) that they should fail. We might be able to persuade the
gbp maintainer that it would be OK to reject configurations
containing % with a message saying substitutions aren't implemented.
(That would be the minimum, because we wouldn't want to set ourselves
up for some programs to write to un-substituted templates as if they
were actual paths.)
Ian.
--
Ian Jackson <[email protected]> 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.
