[Charles, please make sure you read the end of this mail about samtools!]
Hi Michael,
On Wed, Nov 07, 2012 at 08:14:38PM -0700, Michael Crusoe wrote:
> Pardon me, I forgot to 'reply-all'.
No problem (I just mentioned it because I published a "private" mail).
> Yeah, I'm new to Git as well. I've made the
> git.debian.org/git/debian-med/bamtools.git repository, renamed my
> branches, added a pristine-tar based off of the 2.2 release and pushed
> up the whole lot.
I can confirm that git-buildpackage works. I noticed that you keep what
we usually have in branch "upstream" as branch "master" and what we
usually call "master" in branch "debian" but this is fine for me and
obviosely git-buildpackage has no problem with this. I (as a git
beginner) do not see any flaw in this derivation from our policy
document so I'd say this is fine (but I need to check later whether my
job to gather Vcs metadata can copy with this - I think it can)
> >> Okay, I've added the overview of commands:
> >>
> >> Available bamtools commands:
> >> convert Converts between BAM and a number of other formats
> >> count Prints number of alignments in BAM file(s)
> >> coverage Prints coverage statistics from the input BAM file
> >> filter Filters BAM file(s) by user-specified criteria
> >> header Prints BAM header information
> >> index Generates index for BAM file
> >> merge Merge multiple BAM files into single file
> >>
> >
> > Thanks, this is helpful.
>
> You are welcome.
I took the freedom to add further enhancements (git pull).
I also tried to silence lintian about the "merge Merge" string in the
description but failed. :-( I see no reason why and I'm to lazy to do
some deeper inspection - you might like to do this as homework (or we
simply drop the override which now adds another warning, or we could
s/Merge/Merges/ or whatever you feel apropriate.)
> > Hmmm, I wonder whether this is actually a good idea to have versioned
> > binary in this way. Is there any good reason to do so? If yes I would
> > rather try to do some layout like
> >
> > /usr/lib/babtools/...
> >
> > and possibly keep different versions in a reasonable way there which
> > could be dealt by setting PATH properly to refer to a certain version.
> > You could use a symlink /usr/bin/bamtools to the latest version in
> > /usr/lib/bamtools .
>
> The versioned symlink for the binary is from upstream. My aim here was
> to diverge the least amount from what previous users expect.
Hmmm, I keep on having a bad feeling with this approach - but if you as
the maintainer are considering this as the best for your users I will
definitely not insist to follow this gut feeling. However, please use
dh_link rather than having a dangling symlink in debian/ - this is ugly
enough to change it.
> > I have not tested in this case but I'm very positive that debhelper is
> > clever enough to do so even without providing these files.
>
> Testing... Indeed you are correct. I have removed them.
The packaging looks good so far. The only thing I would like you to
consider is the following: If there are any executable tools inside a
library package we usually are creating the following binary package
layout:
libfoo<version> containing *.so
libfoo-dev containing *.a and *.h
foo-tools containing executables in /usr/bin
The rationale is that from a users point of view it is not obvios that a
package strating with lib* contains something to execute and we are not
mentioning those packages in our bio task[1] but rather add foo-tools
there. The package libfoo-dev is mentioned in the according bio-dev
task[2] because it explicitely is targeting at developers.
Would you consider to create a bamtools-tools (well, this sounds like a
stupid name - perhaps only bam-tools or bamtools-utils - whatever might
sound intuitive to you) package? For similarity issues I checked samtools
which is formally lacking the libsamtools<version> package - but it also
does not contain a *.so dynamic library.
Attention to Charles: I just realised that *sam*tools creates a package
lib*bam*-dev containing /usr/lib/lib*bam*.a - somehow this sounds wrong
to me - please verify whether this is OK.
Kind regards
Andreas.
[1] http://debian-med.alioth.debian.org/tasks/bio
[2] http://debian-med.alioth.debian.org/tasks/bio-dev
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108085611.ge17...@an3as.eu
