Idea: sbuild/pbuilder "--dgit" option

Ian Jackson ijackson at chiark.greenend.org.uk
Wed Jan 4 15:13:49 UTC 2017


Mattia Rizzolo writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> Besides, another way would be to just not build the source; there is no
> need for it, as
> 1) the source is already built out of the chroot
> 2) dgit is already able to merge .changes by itself if needed
> so you could just call it with '--debbuildopts -b' (wondering whether
> _this_ needs a shortcut) to only build the binaries, and you have no
> issues whatsoever concerning the source.  I bet this would be a good
> solution for sbuild too.

You mean, the user would run the binaries build themselves with
pbuilder or sbuild or whatever, and then `dgit push' would build the
source, fold it into the .changes file with the binaries, and upload ?

I think this is an unwise workflow.  It would make it far too easy to
accidentally (due to human error, or perhaps bugs) build binaries from
one set of sources, but upload them together with a different set of
sources.

Where a binaryful upload is being prepared, the same invocation (by
the human user) of the same tool should generate both the source .dsc
and the binaries.

Currently with dgit that build rune often has to be `dgit foo-build'.
I would like more people to be able to say `foo-build': in practice,
usually this means `foo-build --dgit'.

This would be better because the user is already used to foo-build,
and because it removes a layer from the wobbly tower of nested build
wrappers.

> No, pbuilder doesn't use debuild (and why would it…), it calls
> `dpkg-buildpackage`.  I know the name of the option '--debbuildopts' is
> a tad misleading, but such is life and I can't really change it now...

Oh...

> > What I was suggesting was that users should, as an alternative, be
> > able to do the build themselves rather than via dgit, and still get
> > the .gitignore included.
> 
> Is such a method (being able to call directly the builder without going
> through the dgit "wrapper") already supported by the other supported
> "backends" of dgit?

That paragraph makes me think you have a wrong mental model.  I'm not
sure what you mean by `backends'.

Running the (source and binary) build by hand, before running dgit
push, already works some of the time, depending on circumstances.  The
.gitignore problem (which is the main reason why using existing build
runes sometimes don't work) only turns up if the package contains
changes to .gitignore.

If you mean "do other build tools like sbuild already have this --dgit
option" then the answer is "no".  Getting a coordinated opinion from
build tool maintainers is what this thread is about :-).

Thanks,
Ian.

-- 
Ian Jackson <ijackson at 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.



More information about the vcs-pkg-discuss mailing list