[Debian-med-packaging] Finishing seqan

Wed Apr 27 08:30:16 UTC 2016

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.

On Tue, Apr 26, 2016 at 9:01 AM, Andreas Tille <andreas at an3as.eu> wrote:

> Ping?  I stumpled upon what it might be the last mail about seqan in my
> inbox.
>
> Any progress here?
>
> Kind regards
>
>         Andreas.
>
> On Fri, Feb 19, 2016 at 10:17:17AM -0800, Kevin Murray wrote:
> > Hi all,
> >
> > Sorry for the delay in responding, I'm still travelling.
> >
> > On 09:06 19/02, Andreas Tille wrote:
> > > On Wed, Feb 17, 2016 at 10:03:31AM +0000, Michael Crusoe wrote:
> > > > >
> > > > > 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.
> > >
> >
> > +1 for sure. There were many bug fixes to programs between 1.x and 2.x,
> without
> > in many cases any change in name, so this should just be treated as a
> normal
> > everyday binary package upstream version increment.
> >
> > > For me using no number for seqan-apps (and mason) is a sensible reason
> > > to drop the version number from the source package these are created
> > > from and consequently also the libraries.
> > >
> > > > 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 don't know about Ubuntu but I think Ubuntu needs to follow library
> > > transitions from Debian in some sensible way anyway.  From my point of
> > > view the seqan transition is a rather simple one with no complex
> > > dependency chains.
> > >
> > > As far as I'm informed BioLinux is quite flexible in taking over
> changes
> > > right from our Git repository - so I do not expect any problem here
> (Tim
> > > in CC to correct my if I'm wrong).
> > >
> >
> > Good point Michael, I think this is a good argument for not changing the
> name
> > of any existing package. seqan1 and seqan2 are sufficiently divergent
> APIs to
> > justify new packages anyway, so I think following the standard transition
> > procedure makes sense (whatever that entails).
> >
> > > > > > 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?
> > >
> > > I understood that its just another binary package splitting the mason
> > > binary out of seqan-apps which is fine since it follows the principle
> of
> > > modularisation.
> > >
> >
> > The seqan-apps package is colossal, and I have a use case involving
> installing
> > just mason's binaries (to /usr/bin, which is not where the seqan-apps
> binaries
> > go due to name conflicts). I didn't realise that mason is already a
> package,
> > and agree that mason2 is a bad name for this package. Let's go with
> > mason-simulator, as that's the name of the project (and drop the version
> per
> > seqan-apps).
> >
> > If at a later date anyone requests similar modularity for other seqan
> apps,
> > then we can do the same then.
> >
> > Thoughts?
> >
> > > > 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.
> > >
> > > I'd consider it worth discussing the package naming with upstream as
> > > well.  I have the strong feeling that we should involve upstream more
> in
> > > our packaging questions - specifically in case of more complex packages
> > > and if upstream is interested.  Upstream has most probably an opinion
> > > what they consider the best way to install their code and we are doing
> > > good hearing their opinion.
> > >
> >
> > <SNIP>
> >
> > +1.  FWIW, seqan already separately distributes their library and
> applications.
> > See http://packages.seqan.de/
> >
> >
> > > > > 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 :-)
> >
> > +1
> >
> > So, to summarise the current opinion (correct me if I'm wrong):
> >
> >
> > src: seqan -> seqan 1.4.2
> > builds: seqan-dev -- devel headers
> >         seqan-apps -- bulk package of all binaries, under
> /usr/lib/seqan/bin
> >         that will be discontinued with the release of the seqan 2.0
> package.
> >
> > src: seqan2 -> 2.1.0 or later
> > builds: libseqan2-dev -- devel headers
> >         seqan-apps -- bulk package of binaries (but those below), under
> >             /usr/lib/seqan/bin
> >         mason-simulator -- Just the mason simulator, upstream name
> 'mason2',
> >             i.e. http://packages.seqan.de/mason2/
> >         libseqan2-doc -- Will eventually house the API/C++ library docs
> >         libseqan2-examples -- will eventually house the sources for the
> demo
> >             programs (note these are separate to the applications) and
> probably
> >             the seqan tutorial documentation (where separate to the API
> >             documentation).
> >
> >
> > I'm OK with dropping the 2 from all seqan2 packages (including src) and
> adding
> > a 1 to all seqan1.x packages, though that will mean that we'll need to
> break
> > reverse build deps etc. So I think Michael's suggestion/action of doing
> a git
> > reset --hard back to the last 1.x release in the seqan git package + the
> new
> > seqan2 repo is the best course of action.
> >
> > Please tell me if any of this is hare-brained in any way :)
> >
> >
> > Cheers,
> > K
> >
> > ---
> > Kevin Murray
> >
>
> --
> 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                          michael.crusoe at gmail.com
Community Engineer                 Common Workflow Language project
*https://impactstory.org/u/0000-0002-2961-9670
<https://impactstory.org/u/0000-0002-2961-9670>*   +32 (0) 2 808 25 52
                                                    +1 480 627 9108
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160427/4a4a90ff/attachment-0001.html>