[Debian-med-packaging] Finishing seqan

[Andreas Tille]

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.

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).

> > > 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.
 
> 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.

In the past I was discussing this with GNUmed developers.  They assumed
Debian had some opinion how a program should be installed.  It took me
some time that I really need a helping hand from them to do it in the
best way for the user.  We are not necessarily experts in the software
we are packaging (at least I'm definitely not).  So we are really glad
to hear opinions from upstream which in turn are sometimes to shy to
rise there opinion.  In GNUmed this ended up for instance that I ask
Upstream for new major versions to write the configuration file they
want to be put in /etc themselves and I just add it to the package.

> > 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 :-)

:-)

Kind regards

     Andreas.

-- 
http://fam-tille.de