[Debian-med-packaging] Finishing seqan
Andreas Tille
andreas at an3as.eu
Tue Apr 26 07:01:45 UTC 2016
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
More information about the Debian-med-packaging
mailing list