Re: [Seqan-dev] Seqan 1.4 : (OpenMS 1.11 packaging in Debian)

[Filippo Rusconi <listes.rusconi@laposte.net>]

<CAO09BL70yVYm3mxsSrAPHXxHT=6Ui0snmZokVKw5+aU01Fwaqw@mail.gmail.com>

Greetings Hannes, and Fellow Developers,

[[ CC seqan-dev@lists.fu-berlin.de as this discussion is relevant to
the seqan developers, who kindly offered to try to find a solution to
the problems that have arisen for Debian packaging after the switch to
svn-based software releases has been implemented ]]

On Tue, Sep 24, 2013 at 02:20:03PM +0200, Hannes Röst wrote:
> I ran into a problem when trying to get the dependencies for packaging
> OpenMS 1.11 which depends on seqan 1.4. Filippo and I found this
> previous conversation
> https://lists.debian.org/debian-med/2013/08/msg00037.html . I hope its
> ok to write to you directly, I didnt quite understand yet where to
> best add comments to a certain bug in debian (maybe you can help me
> here as well?).

1) You get the number of the bug.

2) You copy/paste into your MUA the text of the bug report that is
relevant to the discussion at hand. You write you own stuff.

3) You send your mail to <number>@bugs.debian.org.

For example, the bug that is about seqan-dev is recorded via the
following address:

720995@bugs.debian.org

You CC any person you want.


> Concerning seqan:
> 
> I just asked Knut Reinert directly and apparently all source code of
> the apps is available in the svn tree at
> 
> http://svn.seqan.de/seqan/trunk/extras/apps/

Yes, indeed, that is the problem. That source tree is very
large. We, Debian Developers, would like to have some script feature
that would automatically extract the source code and make
tarballs that are relevant :

- to the library (that is for the seqan-dev package)
- to the binary apps (that is for the -apps package)

How could that be setup ? 

> there is no licence change (still BSD) and probably an oversight on
> their side to not provide the sources of the apps as tar-package.

No, in fact this appears to be a decision. Not an oversight.

> But the source code is in the repository and its all in the build
> system so building it should be as easy as before.

But we need to have a tarball that is unambiguously related to the
version number of the software.

> So a "cmake ." after a fresh checkout of trunk configures all the apps
> on my system and allows you to build them using for example "make
> splazers". For our purposes (e.g. OpenMS building) we mostly need the
> headers anyway which might be nice to have as seqan-1.4.1-dev package
> or so as standalone ...

The seqan-dev package is for the library and it has always been a
library standalone package. The apps were packaged in another deb:
seqan-apps.

> So what would be the best course of action here to get seqan 1.4 packaged?

This is the whole point. 

The last mail of the following thread did seem encouraging:

https://lists.fu-berlin.de/htdig/seqan-dev/2013-August/msg00022.html

The proposal read:

1. The SeqAn team provides a "seqan-src-1.4.1.tar.gz" that essentially
is a tarballed version of the whole SVN tag.

2. The seqan-dev package is built from this using the
-DSEQAN_RELEASE_LIBRARY flag to cmake.

3. The SeqAn team adjusts the build system with a
-DSEQAN_IS_DEBIAN_BUILD=TRUE flag that allows to build the apps using
the headers from the seqan-dev built earlier.


This was looking pretty nice, although one limitation was that the
seqan-src-1.4.1.tar.gz tarball (step 1) would contain the huge SVN tag
stuff. That's, as said above, is too large for us to handle as a
source package as it is filled with stuff that is of no use to the
building of the binary packages.

My suggestion, here, would be that we somehow put into that single
tarball all the code subset that is needed to perform steps 2 and 3.

How about putting that setup into work ? Andreas, would that setup be
a correct one for you ?

Cheers,
Filippo

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer

my massXpert software: http://www.massxpert.org