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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
