[Debian-med-packaging] Finishing seqan

[Andreas Tille]

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