Idea: sbuild/pbuilder "--dgit" option

[Mattia Rizzolo]

On Wed, Jan 04, 2017 at 03:13:49PM +0000, Ian Jackson wrote:
> 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 ?

not necessarily; dgit builds the source, then call
pbuilder/sbuild/whatever to build only the binaries starting from that
source it just built, then merge the .changes.

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

But yes, it's kinda brittle indeed.

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

Ok, I'm sold on this point (especially after today I played a little
more with dgit).

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

backend as in "what actually builds the package", be it pure
dpkg-buildpackage (`dgit build`), sbuild (`dgit sbuild`), etc.
Probably not the greatest of the words to describe it indeed.

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

Ack.
(this is the reply I was looking after with my question)

> 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 :-).

;)


Anyway, I'm still not convinced such --dgit flag to pbuilder/sbuild
is so needed, but yes, I can see it's usefulness.
For pbuilder, feel free to send actionable requests (e.g. a bug with
'please add --dgit option that does xyz as an alias for --foo') - as I
already stated in the past.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20170104/7e8d2d1b/attachment.sig>