On Sun, Nov 16, 2014 at 07:33:32PM +1030, Ron wrote: > On Sat, Nov 15, 2014 at 06:15:33PM +0000, Simon McVittie wrote: > > On 12/11/14 22:07, Ron wrote: > > > I am also interested to hear more > > > about whatever the confusion was you had with this was when you > > > started working with Tollef's systemd repo that you mentioned > > > in the previous thread. > > > > Having played with gitpkg some more, I'm reminded that the answer to > > this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my > > assumption that the contents of the git tree were in a suitable form to > > run dpkg-buildpackage and have a 3.0 (quilt) Debian package fall out. I > > realise that's partly a property of 3.0 (quilt).
Oh, one other thing I probably should clarify about this, that might not be immediately evident to others, is that this isn't actually a problem that gitpkg *requires* you to have. In the case you hit, it was purely a function of the workflow that the person who created that repo chose to use. You could quite equally use a workflow where you do commit your patch series (so that the checked out tree is in the same as one you'd see for the other tools), and gitpkg will quite happily work with that too (and you don't need to enable any hooks to do it if you go that way). If you have any repo where you can run dpkg-bp in the working dir and get a valid package (regardless of how it was created or what other tools were used to do that), then gitpkg can export a source package from it, in its default configuration, with no other hooks. The big difference is gitpkg also gives you the option to use other alternative workflows too, on a repo by repo basis, depending on how the various tradeoffs of doing that balance out for you. Initially, I was rather coy about overspecifying the workflows that *I* thought were useful in the documentation, partly because there was no established best practice and it was quite possible that other people would invent things even better than what I had been experimenting with at the time, if given a free hand to do that and minimal prior brainwashing about "how it should work". That seemed like an opportunity not to waste. But we may be at the stage where we could describe a few of the more proven options in a bit more detail now with less risk to short-circuiting new and useful innovation. [this is another one of those things where I'm really too close to it to easily remember all the things I just take for granted that aren't necessarily obvious to everyone else (yet), without the perspective and input of other people :] Cheers, Ron -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117020239.go10...@hex.shelbyville.oz
