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

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

Hi Andreas,

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

It appears that upstream has moved away from "proper" releases in 2014. Since then, they have tagged what they term "production versions" ( http://www.arb-home.de/downloads.html#Production_version) and uploaded archives here: http://download.arb-home.de/special/manual-builds/. Those are used by the homebrew recipes: https://github.com/arb-project/homebrew-arb/blob/master/Formula/arb.rb.

The changes since 2014 are quite significant, and would certainly justify a 6.1 if not 7.0. Ongoing development focuses on a few research groups at MPI Bremen, however, and they have a CI that updates their local version automatically, so there isn't much incentive for them to go through a full release process. I doubt it will happen in the foreseeable future.

I have been meaning to package one of those "production versions" for Bioconda. But it's hard to find time. ARB is a beast to package, and the extent of the changes means that I probably have to rewrite most of the packaging scripts.

I'm actually wondering whether we should provide static *and* dynamic
libs for all libs which is the default for library packages.

Probably tough to get ARBs Makefiles to do that. The "SL" folder has its name from "static libraries". I can't tell you whether it's even possible to get those to link dynamically. There aren't any consumers and no unit tests that would be easy to use for verification of the package.

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.
Great. Again, thank you a lot for all the work you are putting into this!

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

You mean build SINA against the new libarb package(s)? I guess I can try adding a Debian target to the CI builds for SINA. Do you know which free service is most useful for that and which Debian image I should use?

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:
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.

That sounds reasonable.

I was saying two things:

a) Feel free to copy whatever you have a use for from the Bioconda recipe.

b) It would be good to have the current `libarb` split into libarb-x11 (libAWT/libWINDOW) libarb-no-x11 (libCORE/libARBDB) and libarb-perl (ARB.so).

Looking at libarb, I am seeing now that it does not depend on X11/motif or perl. That sounds wrong. Also, as I mentioned, libARBDB will not work fully without arb_tcp.dat.

You could split ARB into a lot more fine grained things. E.g. have the RPC framework "AISC" with its code generators and code templates completely separate. But I don't really see a use case for that, so probably not worth the effort.
Thanks.  We definitely need your help to find out whether libarb can build
I'll look into it. Where can I find the packages?


Reply to: