Re: FASTX-Toolkit on GitHub.
Hi,
On Tue, Nov 12, 2013 at 09:41:11PM +0900, Charles Plessy wrote:
> > gbp-clone
> > gbp-pull
> >
> > which updates all needed branches. Probably this hint should make its
> > way into policy as well.
>
> Hi Andreas,
>
> In the end I figured out that even if git-buildpackage is not strictly
> necessary, it is sufficiently flexible so that the configuration file in
> debian/gbp.conf will not only allow the use of the standard 'gbp' commands, but
> will also be an efficient documentation of the repository structure.
>
> Here is an example with the htslib package. Its gbp.conf file is the following.
>
> # This package uses pristine-tar, and does not follow the canonical layout of git-buildpackage.
>
> [DEFAULT]
> # the default branch for upstream sources:
> upstream-branch = develop
> # the default branch for the debian patch:
> debian-branch = debian/unstable
> # the default tag formats used:
> upstream-tag = %(version)s
> # use pristine-tar:
> pristine-tar = True
>
> Here, we are following the "develop" branch of the Upstream repository, because
> Upstream recommended so. In other cases, it would often be "master".
>
> To keep the same name for the branches Upstream and in the Debian repository, the
> packaging work is in the "debian/unstable" branch.
>
> We use the upstream tags directly, since we do not use "git import-orig" and
> there is no "upstream" branch
>
> There is a pristine-tar branch, that "git buildpackage" will use to
> reconstitute an upstream tarball if missing.
>
> To populate the pristine-tar branch, I used pristine-tar directly, with the following
> command. The upstream tag 0.2.0-rc3 corresponds to the Debian version 0.2.0~rc3.
>
> pristine-tar commit ../htslib_0.2.0~rc3.orig.tar.gz 0.2.0-rc3
>
> I downloaded the tarball from GitHub via uscan.
OK. As long as this kind of workflows are sufficiently documented (see
below) this is fine for me.
> Now, the problem with the 3.0 (quilt) format is the following: Upstream made a
> few commits since the tag 0.2.0-rc3, but did not tag them. With the 1.0 source
> format, the difference is simply addde to the "diff.gz" file, alongside with
> the debian/ directory. This is the simplest. The 3.0 (quilt) format simply
> fails to build the package in that situation, and brings no advangage since
> there is no need for a patch system. Here, the workflow is to commit a change
> directly and make it available upstream as a Git patch or a pull request.
I have to admit that I'm not really happy with this change. My point is
that we start becoming dependant from a tool (git) which is not
mandatory by policy and not used by everybody. I really dislike patches
merged into the source code (as it is the result of 1.0 format) and it
makes things harder for people who ignore our VCS and try to provide
transparent patches straight according the Debian source. That's why
I would be (strongly) in favour of sticking to 3.0 (quilt) format (until
3.0 (git) is supported properly).
Remark: It might me my Git beginner level which makes my opinion
questionable and so I will nobody stop from switching back from 3.0 to
1.0 but I wanted to express my doubt here.
> Here is the URL for the htslib package (work in progress). I will use Alioth
> as soon as it is repaired. (And update our group policy).
Thanks in any case for updating the group policy about alternative
workflows. I realised (as always) that you recognise the importance of
a service (like alioth) only if it is not available any more. :-(
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: