Re: RFC: DEP-14: Recommended layout for Git packaging repositories
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
Reply to: