Re: Debian-friendly upstream best practices?

[Daniel Pocock <daniel@pocock.com.au>]

> > 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.

Thanks for the quick response

I understand it is not mandatory to use the VCS - the aim of my question 
is just to clarify the way of doing things such that is most widely 
known, e.g. so that other people can rapidly do security-fix NMUs if 
necessary.

For example, I found git-buildpackage is one of the options in the New 
Maintainers Guide, so I figure that if I want to use VCS, I should try 
and do it this way?

I also looked at other things (git format for source packages, and 
git-dpm) but I had the impression those solutions may not be ready for 
widespread use and I should just stick with git-buildpackage if my 
packages are relatively simple?

> > 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.

I understand that maintainers have discretion about these things - what 
I'm trying to establish, are there any traps in using any of these 
approaches?  Have other people with more experience than myself used 
this approach successfully?