Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 12/11/14 22:07, Ron wrote:
> I am also interested to hear more
> about whatever the confusion was you had with this was when you
> started working with Tollef's systemd repo that you mentioned
> in the previous thread.
Having played with gitpkg some more, I'm reminded that the answer to
this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my
assumption that the contents of the git tree were in a suitable form to
run dpkg-buildpackage and have a 3.0 (quilt) Debian package fall out. I
realise that's partly a property of 3.0 (quilt).
For gitpkg, you can commit in the normal git way, but the cost is that
you have to build in a way that isn't the normal dpkg thing (exporting
with gitpkg and building the result).
gbp-pq and git-dpm are the other way round: the tree can be built with
dpkg-buildpackage, but the cost is that you have to commit in a way that
isn't the normal git thing (either using a specific tool, or for the
gbp-pq layout, dropping in pre-prepared patches and hoping they don't
have conflicts, in the same way you might for svn-buildpackage).
I think I was also thrown by the fact that gitpkg does not encapsulate
its configuration in what you commit: if two developers build the same
tree, the debdiff might well be rather large, because one developer's
.git/config results in separate git-debcherry patches and the other's
.git/config results in a single large patch.
git-buildpackage reads both debian/gbp.conf and .git/gbp.conf, with the
latter taking precedence. That lets maintainers provide "executable
documentation, in debian/gbp.conf, for "here is how I intend this repo
to be used", which seems like something that could be rather useful for
gitpkg: for instance, filter patterns for non-DFSG tarball imports can
go in debian/gbp.conf as a way to avoid mistakes.
S
Reply to: