Next take in Debian packaging for Mauve
Hi Aaron,
sorry for this longish mail summarising several issues. I hope you will
find the time to answer all questions below.
I have no idea whether you remember my first attempt to package Mauve
for Debian (which was in 2008[1] - I have never imagined that it would
take such a long time ...). Now I've made way better progress - not
only due to better preconditions inside Debian.
The oldest package in Debian is libgenome version 1.3.1 which resides
inside Debian since 25 Jun 2008 when it could be downloaded from the
formerly used website[2]. This site does not exist any more but the
source code is available from sourceforge[3]. I have no idea whether
there are some important changes in trunk. In any case it would be
helpful to do some release (of any of your relevant libraries and tools)
to be downloadable from the Files section of the SourceForge page.
Recently I have added libmuscle (version 3.7) and libmems (version 1.6)
to the Debian pool. I have created a tarball from the latest trunk.
Also here a proper versioned release would be really helpful. The
rationale is that there is a Debian tool that checks websites for
regular expressions whether new versions might have shown up. This tool
can be easily pointed to the Files section of SourceForge but it does
not work properly on SVN commit IDs.
The next package is mauvealigner which is currently in the Debian NEW
queue[4]. According to the same principle I pulled it from latest trunk
(and the same as for the libraries regarding a proper release applies
here as well). It might last some weeks until it is processed and will
be enter official Debian but I see no problem here.
Finally we come to the Java application Mauve (which is also pulled from
SVN). Regarding Java I need to mention that Debian does allow only
source code but no binaries without source. This does conflict a bit
with the Java strategy to include third party JAR files inside the
source. The good news is that I managed to replace several of these
JARs by Debian packaged equivalents, found out that they are not used
and managed to create a package for a not yet packaged JAR. I would
like you to know this strategy to enable you commenting on it in case I
might have missed something that might harm the final functionality of
Mauve.
After some patches[5] I was able to fully delete the build_support/ dir
in the source dir. Debian contains the needed tools to build Mauve
successfully - so I was able to get rid of it.
Now to the JAR files in the ext/ directory. I noticed that you are
providing BioJava 1.9.2-SNAPSHOT in three different JAR files:
bytecode-1.9.2-SNAPSHOT.jar, core-1.9.2-SNAPSHOT.jar and
gui-1.9.2-SNAPSHOT.jar. Debian contains BioJava in only one JAR file
and this was used to build the package. The possibly weak part is that
Debian has stalled on version 1.7.1 of the BioJava 1.x series. I know
that BioJava 3.x is not fully compatible with the 1.x series but I
wonder
a) Is 1.9.2 really required or is 1.7.1 fine as well for Mauve?
b) Do you intend to convert Mauve to BioJaba 3.x?
Depending from your answer the BioJava dependency might need some work
from our side.
For the following ext/*.jar files I used the according Debian
equivalents: ant-1.7.1.jar (ant 1.9.4), commons-cli-1.2.jar (same
version in Debian), dbus-2.6.jar (libdbus-java 2.8), the classes from
jnlp.jar were found in icedtea-netx-common 1.5.2 and unix-0.5.jar were
found in libunixsocket-java (0.7.3). I guess everything is something
standard and should not cause any trouble.
Regarding postgresql-9.0-801.jdbc4.jar I added a "Recommends" to the
package metainformation which means the package will be recommended at
installation time. In practice this means that per default when the
mauve package is installed also the jdbc4 driver is installed. I wonder
whether at this point only a "Suggests" is fine which would keep the
user installation smaller (without the jdbc4 driver) per default. Do
you think accessing PostgreSQL databases is a frequently used feature or
only something that users might do in exceptional cases?
For ext/jebl-0.4.jar I'm a bit unsure. Debian contains a package of
jebl2[6]. I have no idea how to test whether this works as well as
jebl-0.4. Any hint how to confirm this?
I have created a new Debian package of zeus-jscl. It is in the NEW
queue and this info page has all its metainformation[7]. It seems that
the JAR you added to the Mauve download was using a different (probably
older) zeus-jscl. Thanks to the great Debian community I've git help to
create a patch against Mauve which adapts the code to the new zeus-jscl
interface. I would recommend checking out the patch from here[8] and
take it over to the Mauve code.
Moreover I noticed that ext/jsc.jar does not seem to be used in Mauve
at all. Am I right here? This would be really important since if I
check the download page[9] it says:
Free for non-commercial use. Free educational use is permitted on
courses where students pay no fees and there are fewer than 40 students.
Otherwise email Licensing JSC for commercial use.
This would be regarded non-free by Debian and if Mauve would depend from
this JAR it would not be able to distribute Mauve from main Debian. But
I think it is fine to simply delete it. Can you please confirm this?
My last take is the currently remaining ext/goose.jar. I'm not fully
sure where I can take the source for this JAR from. Somehow it looks
like Cereopsis by Dan Tenenbaum but I would like to get your
confirmation for this first before I'll spent my time into creating a
package from this project. In any case this would be required to follow
the Debian policy that we do not allow binary code. So the way is to
create an appropriate JAR from the source code, create a package from it
and use this instead of ext/goose.jar (in the same manner as I did for
zeus-jscl).
So far for the JARs. Moreover we would like to run the test suite not
only to be sure that my JAR replacements were successful. Debian in
general tries to run any available build time test and has in addition a
test framework which runs automatically from time to time. Since I have
seen a test/ directory I wonder how I could trigger the provided tests.
Last but not least I have a problem with your name choice. In Debian we
just have a package named mauve which is a free test suite for the Java
Class libraries name[11]. While there is no strong reason to rename the
binary we are using as wrapper to start Mauve.jar[12] the package name
has to be changed. (If I remember correctly we discussed this name
choice back in 2008 - to laze to seek.) In general I do not think that
it is a good idea to have the same name twice in the Free Software name
space.
In any case I would like to discuss the package name where users might
be able to find Mauve - you might like to point Debian users to this
package for the simplicity of maintenance and so I'm interested in your
opinion about the following names:
g-mauve
genome-mauve
? (do you have some better suggestion)
Thanks a lot for taking the time to read this longish mail. Any hints
and recommendations regarding the packaging are highly appreciated.
Kind regards and thanks for providing Mauve as Free Software
Andreas.
[1] https://lists.debian.org/debian-med/2008/03/msg00099.html
[2] http://asap.ahabs.wisc.edu/software/software-development-libraries/libgenome.html
[3] http://sourceforge.net/p/mauve/code/HEAD/tree/libGenome/trunk/
[4] https://ftp-master.debian.org/new/mauvealigner_1.2.0+4713-1.html
[5] https://anonscm.debian.org/cgit/debian-med/mauve.git/tree/debian/patches/build_xml.patch
[6] https://github.com/rambaut/jebl2
[7] https://ftp-master.debian.org/new/libzeus-jscl-java_1.72-1.html
[8] https://anonscm.debian.org/cgit/debian-med/mauve.git/tree/debian/patches/use_JConsole_of_zeus-jscl_properly.patch
[9] http://www.jsc.nildram.co.uk/downloads/download.html
[10] https://github.com/dtenenbaum/Cereopsis
[11] http://sourceware.org/mauve/
[12] https://anonscm.debian.org/cgit/debian-med/mauve.git/tree/debian/bin/mauve
--
http://fam-tille.de
Reply to: