[Debian-med-packaging] Finishing seqan

Michael Crusoe michael.crusoe at gmail.com
Wed Feb 17 10:03:31 UTC 2016


Mie, 17 feb. 2016, 10:32, Andreas Tille <andreas at an3as.eu> a scris:

> Hi,
>
> On Wed, Feb 17, 2016 at 07:46:22AM +0000, Michael Crusoe wrote:
> > Agreed that consistent names are good.
>
> +1
>
> > How about the following?
> >
> > source package "seqan1" produces binary package "libseqan1-dev" (version
> > 1.4.2) which provides and conflicts with "seqan-dev" for backwards
> > compatibility. Existing reverse build-dependencies are updated to use the
> > new name on a rolling basis.
> >
> > source package "seqan2" produces binary package "libseqan2-dev",
> > "seqan-apps", "libseqan2-docs" (version 2.1.x)
>
> Seqan-apps is lacking the "2" and I generally do not saa a reason to add
> the version number to both of the source(+binary) packages.  That's why
> I suggested to drop the "2" at all for seqan 2.x in my first mail.  May
> be I misunderstood the suggestion made in Copenhagen.
>

Regardless of what we do, I think seqan-apps shouldn't have a number suffix
as that is installed by users; they shouldn't have to care which source
package it came from. As a reminder: seqan-apps from the 2.1.x series are
the new versions of the same tools in the current 1.4.x based seqan-apps
package. No reason for co-installation of seqan-apps from the 1.4 and 2.x
series.

I think the critical question is: how do these choices affect our
relationship to Debian derivatives and backports to both Debian releases
and releases of Debian derivatives like BioLinux and Ubuntu? I don't have
enough experience yet to answer that question; I am happy to go with
whatever naming scheme makes life easier for backports and derivatives.

(I do know that backports that merely require a rebuild are nicer for
everyone )


> > As for "mason2" that will be confusing given the current unrelated
> package
> > "mason".
>
> ACK. Which keeps me thinking that we could drop the "2" in all cases.
>

Kevin, what's the thinking in packaging mason2 separately? Can't we keep it
a part of the seqan-apps binary package?

Also, I will be going to the SeqAn user group meeting end of March/early
April so I will be able to work directly with the devs to iron out any
issues.


> As said before:  I'll leave the final decision to those who are doing
> the actual work but wanted to raise my optinion here.
>

I appreciate it, keep it coming :-)


> Kind regards
>
>     Andreas.
>
> --
> http://fam-tille.de
>
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
-- 
Michael R. Crusoe     CWL Community Engineer     crusoe at ucdavis.edu
<mcrusoe at msu.edu>
Common Workflow Language project    University of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160217/a34f26f4/attachment.html>


More information about the Debian-med-packaging mailing list