[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Third party code inside Ugene

Hi Andreas,

>  My question was whether you might be possibly able to re-check your phylip integration with the latest upstream source.

The Phylip version we use already has open source license (we use version 3.696)

However you are right, that there were 1 more update to Phylip with some fixes:  version 3.697

I will create a bug in our issue tracking system, so you can track progress for it. I hope it will not take long for us to resolve it.

Thank you,

On 02/01/2019 04:25 PM, Andreas Tille wrote:
Hi Yuliya,

thanks again for the helpful and relieable communication.

On Fri, Feb 01, 2019 at 08:15:29AM +0700, Yuliya Algaer wrote:
Lets start with zlib first: it is easier that way we do not use any custom
flags, renaming and even have initial support to use system library first.

Check this code from ugene_globals.pri:

# By default, UGENE uses bundled zlib on Windows (libs_3rdparty/zlib) and OS
version on Linux.
# To use bundled version on any platform set UGENE_USE_BUNDLED_ZLIB = 1

defineTest( use_bundled_zlib ) {
     contains( UGENE_USE_BUNDLED_ZLIB, 1 ) : return (true)
     contains( UGENE_USE_BUNDLED_ZLIB, 0 ) : return (false)
     win32 {
         return (true)
     return (false)

This way you can switch to the system library: bundled sources will not be
used at all.
I tried this but since in my last packaging (see my other mail) I have
just removed zlib from the source this leads to

    Cannot find file: /build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib/zlib.pro.

in any case - no matter whether I set UGENE_USE_BUNDLED_ZLIB or not.  So
I can easily stick to the patch[1] I've pointed to in my longish mail
from yesterday.  So to do the experiment properly I would need to leave
src/libs_3rdparty/zlib/zlib.pro inside the tarball.  I could consider
this for the next release of UGENE to be able to drop my patch (for sure
I'd prefer the less patches as possible to minimize maintenance needs).
So the next steps for Debian packaging could be:

1) Switch from CMake to qmake build. This is how we build UGENE for
I've done so anyway since it did not build using CMake (I was not aware
that this is only experimental and switched back immediately once you
confirmed this).
2) Try to build it with no bundled zlib. If it works you can completely
remove zlib folder from UGENE sources for Debian and add zlib-dev as the
required dependency.
That's done since yesterday evening.
About Phylip: this is plugin, so it can easily removed from the build &
source code. While most of the 3rd party tools are run from UGENE as
external processes, some of them, and Phylip is the one of them, are
integrated on the source level. Examples of such plugins are: Phylip,
Muscle, HMMER2, KAlign. Unfortunately we can't replace them with pre-built
originals because we integrated them on the source level (modified them).
I think I understood this.  My question was whether you might be
possibly able to re-check your phylip integration with the latest
upstream source.  Besides the license change which would help a lot
regarding packaging there might be some technical progress which could
be interesting for UGENE as well (no matter in what form this might be

The good news is that there are only 4-5 of such plugins, while 90% (like
BLAST, HMMER3...) are run as external programs.
I've now added all those plugins as recommends[2] to the UGENE package
to make sure the plugins are really installed on user machines.  Is
there any way to test that a plugin works?  I want to implement
continuous integration tests and so having one simple test for every
available plugin would be a nice enhancement.
Please let me know if your experiment with zlib is successful. If yes, we
can try the same with SQLite.
As I wrote in my longish mail yesterday I was able to solve this.  However,
if you would enable this more straightforward in the same manner as with
zlib I'd leave the *.pro files and drop my patches.  That would be for
sure helpful.

Kind regards and thanks for your support


[1] https://salsa.debian.org/med-team/ugene/blob/master/debian/patches/debian_packaged_libs.patch
[2] https://salsa.debian.org/med-team/ugene/commit/8507dcdd0233a01814d8a34404c1335b9a78d5b2

Reply to: