Re: Standardizing the layout of git packaging repositories
Hi,
On Fri, 15 Aug 2014, Guido Günther wrote:
> The gbp manual has a recommended branch layout:
>
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
>
> which could serve as a basis. There's plenty of room for improvement,
> e.g. the case where one tracks upstream git isn't yet mentioned (I
> started to follow the above layout also in this case).
Some comments on this recommended layout:
1/ I suggested <vendor>/master rather than <vendor>/unstable (or sid)
because it means we don't have to know the default codename/suite used
for packaging of new upstream versions (in particular for downstreams)
2/ having multiple upstream/<codename> is bound to never be up-to-date
when I do "git checkout debian/experimental && git merge
debian/master", upstream/experimental will get out of sync and I
won't notice it because my package builds just fine
However multiple upstream/* branches can be useful, they should
just match real upstream branches... so things like upstream/master,
upstream/4.8.x, upstream/4.9.x, etc.
3/ I don't see the need for backports/<codename>, I would rather
use debian/wheezy-backports (which actually is just a specific case
of <vendor>/<codename> since wheezy-backports is the Codename in the
Release file)
and security/<codename> is just the continuation of <vendor>/<codename>
after a stable release, so again I don't see the need for a specific
branch here (and if we really need a separate branch, it can again
be <vendor>/<codename>-security)
> > - upstream/<version>
> > (note: we don't need an "upstream" branch, having the good tag for any
> > release that the distros are packaging is enough, it can point to a
> > synthetic commit built with tools like git-import-orig or to a real
> > upstream commit)
>
> Agreed, although having a branch (and recommended naming convention)
> can be useful.
Yes.
> > - pkg/<version>
> > (note: git-buildpackage uses debian/<version> but I find this confusing
> > as we then also have the "debian/" prefix for ubuntu or kali uploads, we
> > don't need the vendor prefix as the usual versioning rules embed the
> > downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
> > any conflict on the namespace, keeping a prefix is important to easily
> > differentiate tags created by upstream developers from tags created
> > by packagers)
>
> The tag format is configurable in gbp and I'd expect downstreams to
> use a different name space (e.g. ubuntu/<version>). This makes it
> simpler to tab complete (or delete) certain groups of tags. A patch to
> make the tag message configurable too is waiting to be applied. pkg/
> is too generic since we'll have more of the RPM support upstreamed
> soonish.
Anything that needs to be configured is a source of error. I'd rather
have gbp do the right thing and pull the information from dpkg-vendor.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: