Re: How to be with SINA that has non-free dependency
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:
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
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
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
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
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?