[Debian-med-packaging] Seqan moved from svn to Git

[Andreas Tille]

Hi Kevin,

On Mon, Sep 28, 2015 at 05:11:28PM +1000, Kevin Murray wrote:
> > As I said that's perfectly fine if it fits a certain need.  As an
> > intermediate step that might avoid running cycles through ftpmaster new
> > queue for new or removed apps you might consider
> > 
> >     seqan-common-apps
> >     seqan-lesscommon-apps (with a better name here for sure)
> > 
> > which might be adapted to user needs while not increasing the maintenance
> > burden to much.
> >
> 
> How about:
> 
>     seqan-apps
>     mason  # for the mason genome simulator suite
>     razerS3
>     ...
> 
> So, per application packages for the most useful few applications, and then a
> catch-all seqan-apps for the rest?

Fine for me since it fits the idea to keep maintenance low since I think
mazon, razers3 are fixed names for the foreseable future.
 
> If you think this is a good idea, I'll start with just seqan's mason genome
> simulator in a separate package, as that's the one I use the most.

It is not about me to decide about good / bad ideas since I do not use
seqan personally.  If it fits your needs just implement it.
 
> To the list/world in general: please chime in if you use any of the seqan
> applications and want them in a separate package.

+1 !!!

> Otherwise I'll guess which
> are the most useful based on citations or something. Or, most likely, just keep
> them all in seqan-apps until someone requests otherwise.

Please add the according citations to debian/upstream/metadata.  There
is the specific field "debian-package" to attache a citation to a
certain binary package.
> 
> Another question Andreas: is seqan-dev or libseqan-dev a better name for the
> headers? I guess it's currently called seqan-dev as seqan is normally referred
> to as "seqan", not "libseqan" (cf. libbz2-dev, libbamtools-dev, etc.)?

You are perfectly right that libseqan-dev fits common practive better.
If we change binary package names anyway for new packages and need to
pass new that this is probably a good point in time to fix this as well.
 
BTW, I think we should upload this package to experimental first and try
whether its dependencies might build properly against this.  I remember
that either bowtie or tophat did not went smoothly since upstream of
these is using a very old copy of seqan and we always need to update the
patches.

Kind regards

      Andreas.

-- 
http://fam-tille.de