[Debian-med-packaging] Finishing seqan

Fri Feb 19 18:17:17 UTC 2016

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