Re: Debian-friendly upstream best practices?
In general, we like it if upstreams follow our guide:
http://wiki.debian.org/UpstreamGuide
On Wed, Mar 28, 2012 at 5:25 PM, Daniel Pocock wrote:
> I am involved in several projects where I am either the founder of the
> project (e.g. dynalogin) or a contributor with full access to the repository
> (e.g. Ganglia, reSIProcate, flactag)
>
> There are also a couple of projects where I don't have any role, but I would
> like to package the code for Debian.
>
> I'm just trying to establish the pattern I should be following
>
> a) for those projects where I have no role, no commit rights, etc, I presume
> that I should just use git-buildpackage, create a distinct repository to
> track debian/ stuff, and follow the normal structure (master and upstream
> branches)
The use of a VCS is completely optional for Debian packaging and for
that matter the choice of VCS for package is completely the choice of
the maintainer, it isn't relevant to Debian.
> b) however, for the other projects where I can potentially include debian/
> stuff in the upstream repo:
>
> - Is there any compelling reason to create a separate repo for
> debianisation? Or it is perfectly fine (in a technical sense) to have the
> debian branch in the upstream repo if nobody else there has objections?
>
> - is it reasonable for the upstream repo to have a Debian branch, inverting
> the normal use-case of git-buildpackage? e.g gbp.conf:
>
> [DEFAULT]
> upstream-branch=master (not upstream)
> debian-branch=debian (not master)
>
> or possibly:
>
> [DEFAULT]
> upstream-branch=master
> debian-branch=packaging/debian
>
> - in the `normal' git-buildpackage use case, I notice `upstream' branch has
> one commit for each real release, yet if git-buildpackage is used with a
> real upstream repo, the `upstream' branch may actually have many small
> commits that are not releases. Does this cause any problems?
>
> - when such a combined repo is used (upstream and debian branches all in the
> same repo), can tagging be handled automatically? I was thinking that tags
> should be in some format such as
>
> 3.3.5
> packaging/debian/3.3.5-1 (or 3.3.5/1 perhaps?)
> packaging/debian/3.3.5-2
>
> - In that example, the 3.3.5 tag is created by the upstream release process,
> not by running git-import-orig - will there be any problem if
> git-import-orig is never run?
>
> From reading the man pages, my impression is that I can use a config such as
> I describe above, and use commands like these:
>
> git-buildpackage \
> --git-tag --git-debian-tag=packaging/debian/%(version)s \
> --git-upstream-branch=master \
> --git-upstream-tree=TAG \
> --git-debian-branch=packaging/debian
>
> git-buildpackage \
> --git-tag --git-debian-tag=packaging/debian/%(version)s \
> --git-upstream-branch=master \
> --git-pristine-tar --git-tarball-dir=/home/daniel/upstream-tarballs/ \
> --git-debian-branch=packaging/debian
>
> Can anyone make any comments on these questions, how I should proceed, best
> examples to follow, howtos I should read, etc?
All the above is completely up to you as maintainer of the Debian packaging.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: