<div dir="ltr">There is a new release of Seqan out (2.1.1); however I don't have time in the near future to work on it, sorry.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 9:01 AM, Andreas Tille <span dir="ltr"><<a href="mailto:andreas@an3as.eu" target="_blank">andreas@an3as.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ping? I stumpled upon what it might be the last mail about seqan in my inbox.<br>
<br>
Any progress here?<br>
<br>
Kind regards<br>
<br>
    Andreas.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Feb 19, 2016 at 10:17:17AM -0800, Kevin Murray wrote:<br>
> Hi all,<br>
><br>
> Sorry for the delay in responding, I'm still travelling.<br>
><br>
> On 09:06 19/02, Andreas Tille wrote:<br>
> > On Wed, Feb 17, 2016 at 10:03:31AM +0000, Michael Crusoe wrote:<br>
> > > ><br>
> > > > Seqan-apps is lacking the "2" and I generally do not saa a reason to add<br>
> > > > the version number to both of the source(+binary) packages. That's why<br>
> > > > I suggested to drop the "2" at all for seqan 2.x in my first mail. May<br>
> > > > be I misunderstood the suggestion made in Copenhagen.<br>
> > > ><br>
> > ><br>
> > > Regardless of what we do, I think seqan-apps shouldn't have a number suffix<br>
> > > as that is installed by users; they shouldn't have to care which source<br>
> > > package it came from. As a reminder: seqan-apps from the 2.1.x series are<br>
> > > the new versions of the same tools in the current 1.4.x based seqan-apps<br>
> > > package. No reason for co-installation of seqan-apps from the 1.4 and 2.x<br>
> > > series.<br>
> ><br>
><br>
> +1 for sure. There were many bug fixes to programs between 1.x and 2.x, without<br>
> in many cases any change in name, so this should just be treated as a normal<br>
> everyday binary package upstream version increment.<br>
><br>
> > For me using no number for seqan-apps (and mason) is a sensible reason<br>
> > to drop the version number from the source package these are created<br>
> > from and consequently also the libraries.<br>
> ><br>
> > > I think the critical question is: how do these choices affect our<br>
> > > relationship to Debian derivatives and backports to both Debian releases<br>
> > > and releases of Debian derivatives like BioLinux and Ubuntu? I don't have<br>
> > > enough experience yet to answer that question; I am happy to go with<br>
> > > whatever naming scheme makes life easier for backports and derivatives.<br>
> ><br>
> > I don't know about Ubuntu but I think Ubuntu needs to follow library<br>
> > transitions from Debian in some sensible way anyway. From my point of<br>
> > view the seqan transition is a rather simple one with no complex<br>
> > dependency chains.<br>
> ><br>
> > As far as I'm informed BioLinux is quite flexible in taking over changes<br>
> > right from our Git repository - so I do not expect any problem here (Tim<br>
> > in CC to correct my if I'm wrong).<br>
> ><br>
><br>
> Good point Michael, I think this is a good argument for not changing the name<br>
> of any existing package. seqan1 and seqan2 are sufficiently divergent APIs to<br>
> justify new packages anyway, so I think following the standard transition<br>
> procedure makes sense (whatever that entails).<br>
><br>
> > > > > As for "mason2" that will be confusing given the current unrelated<br>
> > > > package<br>
> > > > > "mason".<br>
> > > ><br>
> > > > ACK. Which keeps me thinking that we could drop the "2" in all cases.<br>
> > > ><br>
> > ><br>
> > > Kevin, what's the thinking in packaging mason2 separately? Can't we keep it<br>
> > > a part of the seqan-apps binary package?<br>
> ><br>
> > I understood that its just another binary package splitting the mason<br>
> > binary out of seqan-apps which is fine since it follows the principle of<br>
> > modularisation.<br>
> ><br>
><br>
> The seqan-apps package is colossal, and I have a use case involving installing<br>
> just mason's binaries (to /usr/bin, which is not where the seqan-apps binaries<br>
> go due to name conflicts). I didn't realise that mason is already a package,<br>
> and agree that mason2 is a bad name for this package. Let's go with<br>
> mason-simulator, as that's the name of the project (and drop the version per<br>
> seqan-apps).<br>
><br>
> If at a later date anyone requests similar modularity for other seqan apps,<br>
> then we can do the same then.<br>
><br>
> Thoughts?<br>
><br>
> > > Also, I will be going to the SeqAn user group meeting end of March/early<br>
> > > April so I will be able to work directly with the devs to iron out any<br>
> > > issues.<br>
> ><br>
> > I'd consider it worth discussing the package naming with upstream as<br>
> > well. I have the strong feeling that we should involve upstream more in<br>
> > our packaging questions - specifically in case of more complex packages<br>
> > and if upstream is interested. Upstream has most probably an opinion<br>
> > what they consider the best way to install their code and we are doing<br>
> > good hearing their opinion.<br>
> ><br>
><br>
> <SNIP><br>
><br>
> +1. FWIW, seqan already separately distributes their library and applications.<br>
> See <a href="http://packages.seqan.de/" rel="noreferrer" target="_blank">http://packages.seqan.de/</a><br>
><br>
><br>
> > > > As said before:Â I'll leave the final decision to those who are doing<br>
> > > > the actual work but wanted to raise my optinion here.<br>
> > ><br>
> > > I appreciate it, keep it coming :-)<br>
><br>
> +1<br>
><br>
> So, to summarise the current opinion (correct me if I'm wrong):<br>
><br>
><br>
> src: seqan -> seqan 1.4.2<br>
> builds: seqan-dev -- devel headers<br>
>Â Â Â Â Â seqan-apps -- bulk package of all binaries, under /usr/lib/seqan/bin<br>
>Â Â Â Â Â that will be discontinued with the release of the seqan 2.0 package.<br>
><br>
> src: seqan2 -> 2.1.0 or later<br>
> builds: libseqan2-dev -- devel headers<br>
>Â Â Â Â Â seqan-apps -- bulk package of binaries (but those below), under<br>
>Â Â Â Â Â Â Â /usr/lib/seqan/bin<br>
>Â Â Â Â Â mason-simulator -- Just the mason simulator, upstream name 'mason2',<br>
>Â Â Â Â Â Â Â i.e. <a href="http://packages.seqan.de/mason2/" rel="noreferrer" target="_blank">http://packages.seqan.de/mason2/</a><br>
>Â Â Â Â Â libseqan2-doc -- Will eventually house the API/C++ library docs<br>
>Â Â Â Â Â libseqan2-examples -- will eventually house the sources for the demo<br>
>Â Â Â Â Â Â Â programs (note these are separate to the applications) and probably<br>
>Â Â Â Â Â Â Â the seqan tutorial documentation (where separate to the API<br>
>Â Â Â Â Â Â Â documentation).<br>
><br>
><br>
> I'm OK with dropping the 2 from all seqan2 packages (including src) and adding<br>
> a 1 to all seqan1.x packages, though that will mean that we'll need to break<br>
> reverse build deps etc. So I think Michael's suggestion/action of doing a git<br>
> reset --hard back to the last 1.x release in the seqan git package + the new<br>
> seqan2 repo is the best course of action.<br>
><br>
> Please tell me if any of this is hare-brained in any way :)<br>
><br>
><br>
> Cheers,<br>
> K<br>
><br>
> ---<br>
> Kevin Murray<br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
<a href="http://fam-tille.de" rel="noreferrer" target="_blank">http://fam-tille.de</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Debian-med-packaging mailing list<br>
<a href="mailto:Debian-med-packaging@lists.alioth.debian.org">Debian-med-packaging@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="courier new, monospace">Michael R. Crusoe              <a href="mailto:michael.crusoe@gmail.com" style="color:rgb(17,85,204)" target="_blank">michael.crusoe@gmail.com</a><br></font><span style="font-family:'courier new',monospace">Community Engineer          </span><font face="courier new, monospace">Common Workflow Language project<br><font size="2"><font color="#1155cc"><u><a href="https://impactstory.org/u/0000-0002-2961-9670" target="_blank">https://impactstory.org/u/0000-0002-2961-9670</a></u></font>  +32 (0) 2 808 25 52</font></font><br></div><div dir="ltr"><font face="courier new, monospace"><font size="2">                          +1 480 627 9108</font></font></div></div></div></div></div></div></div></div></div></div>
</div>