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 `-
Description: PGP signature
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss