Re: Standardizing the layout of git packaging repositories
On 08/16/2014 07:59 PM, Raphael Hertzog wrote:
> 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)
Well, I have nothing against derivative/downstream distros, but if
you're about to do a new DEP, please consider Debian first. In such
case, debian/unstable makes a lot more sense than just debian/master.
Like I wrote in another post, "master" doesn't express anything.
> 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.
All of this is error prone. Using upstream tags and merging them rather
than branches avoid troubles. I have yet to see a case where using
upstream tags wasn't practical.
> 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)
Right! :)
Thomas
Reply to: