Re: Third party code inside Ugene

[Yuliya Algaer <yalgaer@unipro.ru>]

Hi Andreas!

> -lugenedbd and -lugenedb: what is the difference between these two?

The first one is debug build of the library. The second one is release. All libraries in UGENE are built this way.

> I would recommend to check for the existence of zlib on the system that builds Ugene and if it exists use the zlib from the system.

We can add this check into the build script. But in either case we have to have zlib sources in the bundle UGENE to use it as a fallback.
Another alternative here is to re-check if some compatible form of zlib is available via Qt library. I will check it by myself. Thank you for the hint.


> In case the system has an up to date library there is no need to make use of private copies.

Same issue as with zlib here. If there is no library on the system we have to use the one from our sources or ask a user to provide one. UGENE builds on many platforms. On Windows, for example, there are no SQLite by default at all.


> I'm not sure whether phylip is the only example

Phylip is a plugin and can easily be excluded from the build. The only real UGENE dependencies are QT5, zlib & SQLite. If you do not mind that we carry the last 2 in our sources, but automatically detect and use system ones on Debian (since we know they are compatible) this task is not very complex and I will be glad to help you here.

> By using cmake features you can easily check whether a user has these libraries installed

We have only unofficial experimental build with CMake and have no active plans on it. So we have to use qmake here.

Thank you,
Yuliya.

On 01/30/2019 07:19 PM, Andreas Tille wrote:

Hi Yuliya,

thanks a lot for your quick reply.

On Wed, Jan 30, 2019 at 08:40:45AM +0700, Yuliya Algaer wrote:

Here are the flags we use for SQLite:

DEFINES+=SQLITE_ENABLE_COLUMN_METADATA
DEFINES+=SQLITE_ENABLE_RTREE
unix:DEFINES+=SQLITE_OMIT_LOAD_EXTENSION

Fine.  I've checked the build options in the Debian packaging for sqlite3:

$ grep -R -e SQLITE_ENABLE_COLUMN_METADATA -e SQLITE_ENABLE_RTREE -e SQLITE_OMIT_LOAD_EXTENSION
patches/10-520466-libsqlite3-depends-on-libdl.patch:+  AC_DEFINE(SQLITE_OMIT_LOAD_EXTENSION, 1,
rules:  -DSQLITE_SECURE_DELETE -DSQLITE_ENABLE_COLUMN_METADATA \
rules:  -DSQLITE_ENABLE_RTREE=1 -DSQLITE_SOUNDEX=1 \

This pretty much looks like your requirements to the build options would
be fullfilled.  There is another question about the sqlite3 code copy:
You seem to use two different libs since you are linking sometimes
against -lugenedb and sometimes against -lugenedbd (with _d_ at the
end).  What is the difference between these two?
 

We use no extra flags for zlib.

I would recommend to check for the existence of zlib on the system that
builds Ugene and if it exists use the zlib from the system.  If I would
concentrate on biological software I would not like to spent my time to
provide (and maintain!) default libraries for the users.  I think there
is no modern Linux machine without zlib and featuring Qt is seems less
probable to me than zlib.

These 2 libraries (+Qt) is everything needed to build UGENE. When we
distribute source code for different platforms (MacOS, Windows, Linux) we do
not ask users to install something extra. If a user has Qt5 he will able to
build UGENE with no extra packages at all. This is very convenient for us.

This seems to be convenient at first sight but as I tried to demonstrate
it has some security flaws.  By using cmake features you can easily check
whether a user has these libraries installed (no idea how to check for
command line options for sqlight3).  In case the system has an up to date
library there is no need to make use of private copies.
 

We release updates for UGENE every 2-3 months. I know that Debian & Ubuntu
LTS  do not accept updates from the projects like UGENE after feature
freeze. It makes more beneficial for us to use PPA or ask users to download
the latest version from the website directly.

The Debian Med team is caring for backports[1] in case there is some
request from users (or upstream).  If we can sort out the issues with
UGENE (and for instance can get rid of non-free code inside the download
tarball - I'm not sure whether phylip is the only example) providing a
backport belongs to the tasks the Debian Med team is volunteering to
fulfill.
 

+ You are absolutely right that we need to update our own local SQLite
library. We have never experienced any problems with the old version, but it
will be correct to upgrade. We will do it with the next release.

Thanks a lot.

Kind regards and thanks for your cooperation

     Andreas.


[1] https://backports.debian.org/