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

Re: How to be with SINA that has non-free dependency

Hi Elmar,

On Mon, Jun 10, 2019 at 12:30:15PM -0600, Elmar Pruesse wrote:
> Kudos for getting ARB's library components to build separately! I hope
> that's not going to become to much of a maintenance hassle.

It seems Arb releases are not that frequent to follow the changes

> The libs aren't
> developed to be separate. There have been ABI changes at minor levels
> (including code compiled dependent on C++11/C++14/C++17 flags in the
> compiler IIRC). I'd recommend requiring exact version matches.

That's a good reason to add symbols files.

> SINA detects
> available API at compile time (see sina/m4/arb.m4) and is compatible with
> ARB 5, ARB 6.0.x and 6.1.x so far.

Thanks for the warning in any case.
> > > configure:16724: error: in `/<<PKGBUILDDIR>>':
> > > configure:16726: error: Required libraries found missing:
> > >    ARB PROBE library (PROBE_COM/client.a)
> > >    ARB HELIX library (SL/HELIX/HELIX.a)
> Check whether those files have any symbols in them. IIRC there was an issue
> with the Debian libarb-dev package where the symbols where stripped from the
> static libs, making them useless. I think I filed a bug report at some
> point, just didn't have time to mess with it and come up with a patch.

I'm actually wondering whether we should provide static *and* dynamic
libs for all libs which is the default for library packages.
> The client.a (and in some versions common.a) files contain the RPC client
> code for connecting to the ARB servers (PT server and Name server). The
> framework is called AISC. IIRC those components are covered by the free
> license. I'm not sure about HELIX.a. If necessary, I can make that part of
> SINA optional.

HELIX is mentioned in the license text explicitly.  However, there are more
files and dirs which are not yet covered.  My plan is to approach upstream
once we are sure that we now have all code we need.
> > That's good news in so far that these libraries are inside libarb-dev
> > package in
> > 
> >      /usr/lib/x86_64-linux-gnu/arb/PROBE_COM/client.a  and
> >      /usr/lib/x86_64-linux-gnu/arb/SL/HELIX/HELIX.a
> > 
> > So that's probably a configuration issue.
> The code detecting the location for ARB's static/dynamic libs is in
> sina/m4/arb.m4. Since ARB does not comply with FHS, the locations vary a lot
> depending on distribution mechanism - it's been tough to get that right and
> every time I change something it breaks under some condition. I will be
> happy to help or accept patches though. Also, if you want to add that file
> to the libarb-dev package, I'm happy to add whichever license you think is
> most suitable.

I wonder whether you can try to build SINA against these packages.  You
know the code way better than Liubov (or anybody else).  I've moved the
lib to the multiarch dir to comply with FHS to address what you raised
> The libAWT.so and libWINDOW.so libraries contain the ARB windowing toolkit
> and are the parts requiring X11 and motif. Only the GUI driven components of
> ARB depend on those (the ARB PT server e.g. does not). They are not required
> for SINA.

Thanks for this confirmation.  This is really helpful.
> You are also very welcome to take anything from the Bioconda arb package
> ("arb-bio" due to name space collision with the arbitrary precision math
> library). The files are here:
> https://github.com/bioconda/bioconda-recipes/tree/master/recipes/arb-bio.
> For those packages, I split ARB into libarbdb-dev (static libs), libarbdb
> (ONLY libARBDB.so, libCORE.so and arb_tcp.dat to avoid X11 dependency),
> arb-bio-tools (non-X11 dependent binaries such as PT server) and arb-bio
> (the rest). I'm not certain how the Debian setup is currently, but since the
> aim is to package Qiime2, avoiding X11 would probably be nice.

I'm not sure whether I understand fully what you are proposing.  I think
more fine grained packages (one dynamic lib per package) has the
advantage of easier creation of symbols files.  I might consider this
but I wanted to keep things as simple as possible for now to just see
whether we have all code we need under a free license.
> Thank you all for your awesome efforts! Please feel free to open issues at
> SINA's github for anything I can do upstream.

Thanks.  We definitely need your help to find out whether libarb can build

> I'm sorry that I can't help
> with the ARB license itself.

We understand this - no need to sorry.

Kind regards



Reply to: