On Fri, Sep 21, 2007 at 07:42:52AM +0200, Mike Hommey wrote: > On Fri, Sep 21, 2007 at 10:49:26AM +0930, Ron <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
