Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
Hi,
On Wed, Nov 07, 2012 at 01:27:50PM -0700, Michael Crusoe wrote:
> > Debian packaging at git.debian.org as it is described in Debian Med team
> > policy[1] which has a lot of advantages that might not obvious at first
> > sight (I'd happily elaborate on this if you are curious what these might
> > be.) I'd volunteer to create an initial repository - write access should
> > be easy for you because I just verified that you are member of the Alioth
> > project.
>
> I have no strong feelings though I like having the packaging data
> hosted in such a way as to preserve all the git history for the
> software itself. Would that still be possible?
I admit I'm definitely not a Git expert and thus I'm CCing your (not so
private mail) to the list (and we should keep the discussion here).
Usually we do commit the source release of each packaged version using
pristine-tar - just as it is described in Debian Med policy[1] in the
"Git tips" section. I do not have any strong opinion to have more
detailed history as long as the branches and tags we are using are
properly set to enable git-buildpackage working.
> > I intended to answer in response to your ITP bug that a long description
> > is missing and it is also basically missing in your debian/control file.
> > Please try to find a more verbose description for the binary packages.
>
> 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
> random Select random alignments from existing BAM file(s), intended more as
> a testing tool.
> resolve Resolves paired-end reads (marking the IsProperPair flag as needed)
> revert Removes duplicate marks and restores original base qualities
> sort Sorts the BAM file according to some criteria
> split Splits a BAM file on user-specified property, creating a new BAM
> output file for each value found
> stats Prints some basic statistics from input BAM file(s)
Thanks, this is helpful.
> > File libbamtools2.2.0.manpages: Are you sure that you want to install
> > debian/bamtools-2.2.0.1 as manpage? The file name does not look at
> > all like a manpage - I would simply remove this file
>
> It appears the second line fails. I created it in response to a
> lintian warning as the binary is shipped as 'bamtools' and a symlink
> with the name 'bamtools-2.2.0'
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 .
> > Files *.postints / *.postrm: These files are looking like usual
> > templates. I have not seen any specific use. Did I missed something?
>
> I believe debhelper adds in ldconfig commands.
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.
> > 3. get-orig-source: see below
> >
> > Missing file debian/watch: It seems bamtools relies totally in Git to
> > distribute the source. I admit we are facing such situations more and
> > more however, my personal opinion is that we should try to recommend
> > upstream to do some versioned source tarball releases to enable tools
> > like uscan detecting new versions. You could write a reasonable
> > debian/watch file which would make the get-orig-source target in
> > debian/rules unneeded. You seem to be connected to upstream and I would
> > like you to propagate this idea.
>
> I believe if upstream tags using version number then the uscan is
> fairly trivial. I've contacted them about this. Thanks for the
> reminder.
Fine.
Kind regards
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
http://fam-tille.de
Reply to: