Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git

[Ron <ron@debian.org>]

On Fri, Sep 21, 2007 at 07:42:52AM +0200, Mike Hommey wrote:
> On Fri, Sep 21, 2007 at 10:49:26AM +0930, Ron <ron@debian.org> wrote:
> > Package: wnpp
> > 
> > * Package name    : gitpkg
> >   Description     : helper scripts for maintaining packages with git
> > 
> >  This packages provides some simple scripts that assist with maintaining
> >  Debian packages in git.
> >  .
> >  gitpkg        - creates a source package from tagged revisons.
> >  git-debimport - creates a git repository from a set of existing packages.
> 
> Couldn't that be merged with git-buildpackage ?

Well, they are kind of orthogonal, so I don't really see what sense that
would make.  If you are using the git-buildpackage framework, then you
don't really need these scripts -- but you can use gitpkg to create a
source package from almost any repo with a half-sane structure, not just
ones in some carefully pre-determined form.  All you need is source for
a valid package in the repo, and knowledge of the tag/branch/commit that
you wish to roll the package from.  gitpkg will figure out all the rest
for itself automagically.  You can pluck a package from almost any
arbitrarily named point of almost any repo.

So if you are using gitpkg, you probably don't need git-buildpackage
either.  I've split this out as a standalone command after it became
apparent that the snippets I'd been putting into makefile targets in
various projects to do this could easily be generalised to run as an
external agent, maintained in one place for (and instantly added to)
all of them.

git offers too many degrees of freedom, which different projects might
profitably exercise, to put development through the bottleneck of an
old-style framework.  I think we can, and need to, think differently
about this, and this script is an exploration of that.

I know I'm not the only one who feels that git-buildpackage is not
'right' for them, and this is my best answer to that problem to date.
To point out a couple of concrete problems above and beyond prescribing
the repo layout:

Looking at the manual page for git-buildpackage, it would appear that
you can in fact only build packages from the current HEAD of a branch...
Is that really true?  If so, it sort of misses the point of keeping
all those old package versions in revision control.  If you can't go
back and perfectly reproduce an old package, then you still need to
keep the old packages themselves too...  krusty, say it ain't so?

My latest problem with tools from the git-buildpackage suite was with
git-import-dsc.  After discovering, to my horror, than none of the
cvs import tools seem to be able to get a cvs-buildpackage repo
correctly exported to something usable in git, I decided to forego
the detailed history in preference to being able to extract the old
packages again with perfect fidelity.  I've still got the old repo's
I can examine, and it won't be too long before that's mostly all
ancient history anyhow ...  so I decided to import all my old .debs
directly.  And was most surprised to learn that git-import-dsc can
only import one .deb per repo.  That's it.

So in the last few hours git-debimport was born to automate importing
them all.  Its much cruder and less polished that gitpkg, but its also
a one-shot tool and you won't keep using it like you might gitpkg.

I've had the gitpkg script up for people to poke at on the p.d.p url
for a few weeks now, and its been used in anger on a few packages,
and used in makefile target form for much longer than that.
I've mostly packaged it for my own convenience, but uploaded it to
share the love around.

I don't profess that its in anything like a final form, but if it
provokes some discussion on Better Ways To Do Things, then I'm all
for that.  If the git-buildpackage maintainer would like to pinch
or offer ideas I think that would be great.  If other people find
it useful or find ways to improve it, then maybe we are on to
something.  If not, it will become obsoleted by something better
and I'll be happy to chalk it up as Something I Don't Need To Do
Anymore ...

Anyhow, that's about 10x more text than it took to actually
implement it.  It's already uploaded waiting in NEW and if you
can't wait that long, its a single file with built in help that
you can grab from my p.d.o space.

Have a play with it.  Then we can have a constructive discussion
about what it is and where it belongs.

Cheers,
Ron