Re: Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git
On Thu, Oct 04, 2007 at 04:08:33PM +0200, Guido Guenther wrote:
> On Thu, Oct 04, 2007 at 05:40:04PM +0930, Ron wrote:
> [..snip..]
> > 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.
> That's fine if you're a working on all of your packages alone, things
> get more interesting in case of co-maintenance. Where I use
> git-buildpackage a lot, several people are co-maintaining about 100
> packages (and more and more packages keep moving from svn to git). In
> this case you want consistent tag and branch naming, make sure tags are
> named and signed correctly, etc. The many degrees of freedom of git make
> it a great tool but you have to add some naming policy on top of that in
> order to work together efficently - that's what git-buildpackage tries
> to do - without getting into the way of the user too much.
Sorry, perhaps I wasn't clear there. I'm not advocating total chaos
inside any single repo, or any group of repos maintained by the same
people. Localised consistency in these things is highly desirable,
for all the reasons you mention and more. The issue I see is that
global consistency is an impossible goal, there are already many such
conventions among different groups and its highly unlikely they will
ever converge without some really compelling reason and a lot of
renaming of existing branches/tags in existing repos.
If I'm pulling an upstream branch from such a source I have two choices,
re-tag it and rename its branches, or deal with the upstream system and
minimise confusion when communicating with them about tag/branch names.
The latter seems consistent with things like using upstream coding style
even if it doesn't match my own preferred one, and since I already do
have repos where people have chosen a variety of styles (and will surely
wind up with more of them), it seemed preferable to me to separate such
policy from the tool and just let it deal with the mechanism of producing
a source package from any arbitrary repo. You can use git hooks in the
repo to enforce such policies locally if desired/required where a simple
clue bat doesn't suffice.
> > 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.
> Well, I think they aren't if you intend to work with others.
They are still independent of the task of extracting a source package
(which is all the gitpkg script specialises in), even where broader
conventions for such things also apply. In the case of a tool like
gbp though, which combines several of these operations (tagging the
repo, building the package binary) then policy, procedure, and
mechanism are all much more tightly bound together indeed.
This is the curse of frameworks in general. You trade your ability to
work in heterogeneous environments for the convenience of performing
certain functions by rote. That doesn't necessarily make them Bad,
it just makes them difficult or impossible to use in circumstances
that they didn't envisage or assume when they were first created.
Sometimes that's a win. Looking at how my own personal usage was
evolving in this case though, it seemed like an unnecessary limitation
that could be fairly easily avoided by dividing the problem into
smaller chunks. These extra operations can be easily layered onto
gitpkg with additional more specialised scripts, and probably will
be as my habits refine themselves to further scriptable repetition.
> > 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.
> I don't see why this can't be done with git-buildpackage too. While you
> do:
>
> gitpkg branch1 branch2
>
> git-buildpackage does:
>
> git-buildpackage --git-debian-branch=branch1 --git-upstream-branch=branch2
The biggest practical difference there right now (aside from the amount
of typing ;) is that the former is actually:
gitpkg tree-ish [tree-ish]
I agree that is an improvement that shouldn't be too hard to apply to
gbp too though, but I'm not sure how deep the assumption of being on
a branch HEAD really runs in it.
To give a real world example of why this is important to me in a
collaborative environment: I have several repos where the source is
also published in forms other than .deb and where releases are actually
checked by a 'real' qa team before they are published. This means a
release candidate will get tagged, but other commits will continue to
be made to the main branch before the qa team signs off on the
candidate. Since they are testing source pulled from git (not the
debs per se), the debs won't get rolled and tested until the source
itself is proven ok. This means I regularly make .debs from source
other than the branch head and that the .deb version/changelog only
gets incremented for actual releases, not for every candidate that is
proposed (and possibly rejected).
If you are pulling upstream source directly (as opposed to importing
tarballs on an upstream branch), then the upstream branch may have
similar issues, the tagged release that you want to make a deb of
may no longer be their HEAD commit at the time you make it, even if
your deb branch is at its current head. You may even want to package
from a commit slightly later than their tagged release if some errata
was committed shortly after that (as an alternative to cherry picking
what is really a fast-forward on the upstream branch).
gitpkg also copes automatically with 'debian native' packages and
repos that aren't debian native but where everything is on a single
branch (I don't really recommend the latter given the choice either,
but it is a trivial case to handle ;). It's not clear to me if gbp
can handle them yet either?
> > 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.
> Same here. Thanks for the explanation.
I'd likewise welcome any critique of gitpkg where it falls short
for people. It should work on a gbp repo as well as any other.
Best practice is very clearly still evolving here so information
about what does and does not work for people is most valuable to
have while we explore this.
As I think I mentioned previously, this started as some simple
makefile snippets for a 'debdist' target that I'd been adding
to various projects, which got factored out as a non intrusive
tool that could be used with any project in git without requiring
addtional local modifications.
Its been doing what I need from it fairly nicely so far (and was
self-packaging from the very first commit ;). If it evolves into
something more widely useful, or its key strengths get absorbed
into some other tool, then publishing it will have certainly been
time doubly well spent for me.
git has already enabled me to rethink old habits in some very
constructive ways, but I do get the feeling this is still very
much just the beginning of that...
Cheers,
Ron
Reply to: