Re: Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git
Hi Guido,
On Wed, Oct 03, 2007 at 04:03:36PM +0200, Guido Guenther wrote:
> On Fri, Sep 21, 2007 at 04:53:34PM +0930, Ron wrote:
> [..snip..]
> > 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:
> It'd be more than happy to hear about possible improvements.
For me its really more a philosophical difference in how I'd like to
work in future. git-buildpackage is something of a 'framework', in
that it sets out ways I should do things, then tries to do them all
for me as a convenience if I follow its way of working.
While that sort of does make it the logical complement to all the other
*-buildpackage systems, and was something of a necessity in the original
cvs-buildpackage implementation, I'm not really sure that is so necessary
when working with git, or even really desirable.
gitpkg has a much more narrow focus and concerns itself solely with the
task of generating a valid Debian source package from a(ny) git repo.
It takes just a tag (of any tree-ish form) indicating the version to
release (or two tags if you have separate debian and upstream branches)
and builds a source package of the correct form based on the content
retrieved.
How you arrange the repo, how you label your tags, when you apply them,
and how you build your packages after that are entirely independent.
So if you happen to have many different git repos, all using different
conventions for these things, you can still use the same tool, without
needing to modify its config, to extract source packages from all of them.
Likewise if you have a repo with many 'upstream' branches, or even many
Debian branches. gitpkg doesn't care, it just needs you to tell it on
the fly which one(s) you want to release from this time.
Anyhow, that's why I saw this as a separate experiment to make rather
than an 'improvement' that could be easily made to git-buildpackage.
We are aiming at much the same result though, so I'd be more than
happy to see ideas shared between the different schools of thought
on how to best manage packages with git.
You might also like to talk to David Nusinow, the experiences of the
X team have been pushing the bounds of available tools also.
> > 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...
> Which simply results from the fact that *branching* itself ist so
> awfully cheap, you just do:
>
> git-checkout -b branch branchpoint_most_likely_a_tag
>
> and build from there - done. This could easily be added to
> git-buildpacakge itself but would just add commandline options for real
> gain.
Ok, that makes some sense (I figured there had to be _some_ way, if this
is it then a note in the docs would be helpful, I agree an option to do
it would be less so).
It still seems a bit suboptimal to me though, since git-archive can
pull source from any tree-ish, not just a branch head. How much that
affects individuals will vary from user to user though. In my case
the release I want to make can be fairly commonly no longer the head
though, so this being trivial (and not adding extra overhead to the
repo) is important to me.
> > ... surprised to learn that git-import-dsc can only import one
> > .deb per repo.
> This indeed is a limitation of git-import-dsc that could quiet simply be
> fixed if this should be needed.
I'm not sure this is totally trivial to do correctly in the general
case, even git-debimport only does it well enough for a few packages
I needed to do it with (and got custom hacked for a few others).
It would be nice to have better tools for importing source from
old debs and other *-buildpackage repos though (my cvs-buildpackage
repos don't seem to do well with the cvs -> git tools currently
available).
I guess the trouble with that is that once people have processed
their own repos its not something they'll keep needing to do, so
work on this seems to have been a bit ad-hoc, and always ends
before a really general purpose and robust tool gets created...
If someone reading runs a CS class, it might make a good term
project though ;)
Best,
Ron
Reply to: