Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
On Thu, Nov 08, 2012 at 01:45:39AM -0700, Michael Crusoe wrote:
> On Thu, Nov 8, 2012 at 12:19 AM, Andreas Tille <andreas@an3as.eu> wrote:
> > On Wed, Nov 07, 2012 at 08:59:27PM -0700, Michael Crusoe wrote:
> >> On Wed, Nov 7, 2012 at 6:21 AM, Dominique Belhachemi <domibel@debian.org> wrote:
> >> > It is also possible to remove the third party code from the source tarball
> >> > and from debian/copyright.
> >>
> >> I've removed it from the master branch and modified the copyright.
> >> What is the best way to update the source tarball?
> >
> > If it is removed from the master branch (you are refering to upstream,
> > right?) than it might make sense to release a new minor version.
>
> I may have mispoke. I removed it from the debian branch.
OK. Unfortunately it remains in the pristine-tar and when using
git-buildpackage it creates a tarball including the third_party dir. If
I simply use the get-orig-source target and drop the result in
../tarballs I can trick git-buildpackage with this new tarball. Works
somehow but hmmm, its a bit hackish. We could end up with a situation
where somebody else would like to rebuild the package, will trust what
is in pristine-tar and ends up with an upstream tarball with different
MD5 sum which will be rejected at the Debian mirror. So fixing
pristine-tar would make really sense - unfortunately I have no idea how
to do this properly. I tried
$ git import-orig --pristine-tar ../tarballs/bamtools_2.2.orig.tar.gz
What is the upstream version? [2.2]
gbp:info: Importing '../tarballs/bamtools_2.2.orig.tar.gz' to branch 'master'...
gbp:info: Source package is bamtools
gbp:info: Upstream version is 2.2
pristine-tar: committed bamtools_2.2.orig.tar.gz.delta to branch pristine-tar
fatal: tag 'upstream/2.2' already exists
gbp:error: Couldn't run git tag: git returned 128
gbp:error: Import of ../tarballs/bamtools_2.2.orig.tar.gz failed
so this does not do the trick. :-(
> > Otherwise it would make sense to write a debian/get-orig-source script
> > and call this in the get-orig-source target of debian/rules. There are
> > a plenty of examples in Debian Med repository - feel free to ask for a
> > more detailed link.
>
> Blergh. That combined with the lack of proper tagging upstream makes
> for a messy propisition.
Yep. A fair amount of Debian package maintenance is teaching upstream.
As I said in the beginning: It would be *really* helpful if upstream
would consider providing release tarballs at some http location. We
could write a debian/watch file and would have way less burden to get
the source properly.
BTW, please do `git pull` for some changes in the get-orig-source target.
Anything about replacing the dangling symlink by a dh_link call by using
a libbamtools2.2.0.links file?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: