New version of filo or what git workflow for software without release tarball (Was: FASTX-Toolkit on GitHub)
Hi Charles,
in my effort to update long unattended packages I stumbled upon filo and
I noticed that there is a patch in upstream Git that is not incorporated
in our package. IMHO the fact that we have no means to get automated
notification about new upstream changes (the change was "2 years ago)
makes this approach flawed but it seems in this specific case we will not
see more updates any time soon.
I fully quoted your mail about htslib because we have a similar case
where we could simply rely on a Git clone rather than a release tarball.
If I should upgrade the package I would "simply" (probably my workflow
is not that simple) write a get-orig-source target, creating an upstream
tarball and would inject it as pristine-tar. This would strictly follow
the workflow described in policy. But it would be OK for me as well if
somebody else would do some more fitting way / give some detailed advise
I could follow to try new things.
Kind regards
Andreas.
[1] https://github.com/arq5x/filo/commit/3c9fb01843d797c64be578ecbcd1be683cfe245a
On Tue, Nov 12, 2013 at 09:41:11PM +0900, Charles Plessy wrote:
> Le Mon, Nov 11, 2013 at 08:21:28AM +0100, Andreas Tille a écrit :
> > On Mon, Nov 11, 2013 at 08:45:09AM +0900, Charles Plessy wrote:
> > >
> > > Indeed, one would need to download it using apt-get source, or from the
> > > upstream system for browsing Git repositories (here, GitHub). Pristine-tar
> > > brought us as much pain as gain, so I am tempted to go without. Nevertheless,
> > > it is totally conceivable to maintain a pristine-tar branch (perhaps without
> > > git-buildpackage).
> >
> > I admit I have no problem with pristine-tar any more since I
> > consequently use
> >
> > 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.
>
> 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.
>
> 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).
>
> https://github.com/Debian/htslib
>
> Have a nice day.
>
> --
> Charles Plessy
> Debian Med packaging team,
> http://www.debian.org/devel/debian-med
> Tsurumi, Kanagawa, Japan
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20131112124111.GA18517@falafel.plessy.net">http://lists.debian.org/[🔎] 20131112124111.GA18517@falafel.plessy.net
>
>
--
http://fam-tille.de
Reply to: