<br><br><div class="gmail_quote"><div dir="ltr">Mie, 17 feb. 2016, 10:32, Andreas Tille <<a href="mailto:andreas@an3as.eu" target="_blank">andreas@an3as.eu</a>> a scris:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Wed, Feb 17, 2016 at 07:46:22AM +0000, Michael Crusoe wrote:<br>
> Agreed that consistent names are good.<br>
<br>
+1<br>
<br>
> How about the following?<br>
><br>
> source package "seqan1" produces binary package "libseqan1-dev" (version<br>
> 1.4.2) which provides and conflicts with "seqan-dev" for backwards<br>
> compatibility. Existing reverse build-dependencies are updated to use the<br>
> new name on a rolling basis.<br>
><br>
> source package "seqan2" produces binary package "libseqan2-dev",<br>
> "seqan-apps", "libseqan2-docs" (version 2.1.x)<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></blockquote></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(I do know that backports that merely require a rebuild are nicer for everyone )</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> As for "mason2" that will be confusing given the current unrelated package<br>
> "mason".<br>
<br>
ACK. Which keeps me thinking that we could drop the "2" in all cases.<br></blockquote></div><div><br></div><div>Kevin, what's the thinking in packaging mason2 separately? Can't we keep it a part of the seqan-apps binary package?</div><div><br></div><div>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.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote></div><div><br></div><div>I appreciate it, keep it coming :-)</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kind regards<br>
<br>
    Andreas.<br>
<br>
--<br>
<a href="http://fam-tille.de" rel="noreferrer" target="_blank">http://fam-tille.de</a><br>
<br>
_______________________________________________<br>
Debian-med-packaging mailing list<br>
<a href="mailto:Debian-med-packaging@lists.alioth.debian.org" target="_blank">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>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><span style="color:rgb(34,34,34);font-family:'courier new',monospace;font-size:small;line-height:normal">Michael R. Crusoe     CWL Community Engineer     </span><a href="mailto:mcrusoe@msu.edu" target="_blank" style="color:rgb(17,85,204);font-family:'courier new',monospace;font-size:small;line-height:normal">crusoe@ucdavis.edu</a><br style="color:rgb(34,34,34);font-family:'courier new',monospace;font-size:small;line-height:normal"><span style="color:rgb(34,34,34);font-family:'courier new',monospace;font-size:small;line-height:normal">Common Workflow Language project    University of California, Davis</span><br style="color:rgb(34,34,34);font-family:'courier new',monospace;font-size:small;line-height:normal"><a href="https://impactstory.org/MichaelRCrusoe" target="_blank" style="color:rgb(17,85,204);font-family:'courier new',monospace;font-size:small;line-height:normal">https://impactstory.org/MichaelRCrusoe</a><font size="2" style="color:rgb(34,34,34);font-family:'courier new',monospace;font-size:small;line-height:normal"> <a href="http://twitter.com/biocrusoe" target="_blank" style="color:rgb(17,85,204)">http://twitter.com/biocrusoe</a></font><br></div>