Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
On Wed, Nov 7, 2012 at 1:52 PM, Andreas Tille <tille@debian.org> wrote:
> 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.
Pardon me, I forgot to 'reply-all'.
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 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.
You are welcome.
>> > 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 .
The versioned symlink for the binary is from upstream. My aim here was
to diverge the least amount from what previous users expect.
>> > 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.
Testing... Indeed you are correct. I have removed them.
--
Michael R. Crusoe
Reply to: