Re: How to be with SINA that has non-free dependency
Hi Elmar,
On Mon, Jun 10, 2019 at 03:50:53PM -0600, Elmar Pruesse wrote:
> > It seems Arb releases are not that frequent to follow the changes
> > frequently.
>
> 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.
Hmmm, what makes ARB so hard to deal with from a packaging point of view
is that upstream uses a manually crafted build system with many hacks.
It would be extremely valuable to switch to something like automake or
cmake. Usually the effort to standardize the build system is quiete a
good investment into the future.
Same with using standard hosting platforms that are simplifying the
release process. I do not know any valid reason why any project should
not be able to make use of these.
> 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 have no idea about BioConda packaging so I can not comment on this.
If you see some some advantage to point the Debian watch file to the
manual-builds you are mentioning above (with latest code from
2018_10_19[1]) please let us know. We might consider using this for the
next arb package release (and as you said also for libarb due to the
strict version dependency).
> > 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.
Yes, the main Makefile has some switch for this. It defaults to dynamic
and may be its possible to build the lib twice (once set with dynamic
once with static).
> 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.
I do not intend to gain for academical completeness regarding Debian
library packaging. While I doubt there would be no chance to create
dynamic libraries from this code I see no practical relevant reason
for diving even deeper here.
> > 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!
You are welcome.
> > 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
> > above.
>
> 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.
May be building SINA at all by using the said libarb package would be
sufficient for the moment. Can you help Liubov with some hint?
> Do you know which free
> service is most useful for that and which Debian image I should use?
Sorry, I have no idea. Once we have an official SINA package we can
integrate it into Debian CI infrastructure by providing an autopkgtest.
> > > 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.
>
> 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)
The AWT/WINDOW code was not listed under the dirs which are covered by
the free license. So we will not package this (since you confirmed that
it is not even needed by SINA which is our current target).
> libarb-no-x11 (libCORE/libARBDB) and libarb-perl
> (ARB.so).
ARB.so is also not created by the free code and I also understood that
this is not needed for SINA.
> Looking at libarb, I am seeing now that it does not depend on X11/motif or
> perl.
May be I misunderstood you: Didn't you said that neither X11 nor perl
is needed by SINA? My strategy was:
1. Build all dirs that are mentioned to have a free license + the
additional code that was needed in the build process.
2. Get confirmation that this is sufficient to build SINA
3. Ask ARB upstream to relicense the missing pieces to build all
code we need for SINA
4. Make a decent library package to build SINA.
5. See what pieces of current non-free libarb need to be assembled
in a libarb-non-free package providing the remaining things that
are currently in the libarb package created with the arb source
package. But that's for **later** since we prefer to work on
the free code base.
It is *not* intended to create a 1:1 replacement for the non-free libarb
package which is currently build from arb source.
> That sounds wrong. Also, as I mentioned, libARBDB will not work fully
> without arb_tcp.dat.
So you want to say that we should move this from
package arb /etc/arb/arb_tcp.dat
to the newly build
package libarb /etc/arb/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.
>From my perspective arb is non-free and thus gets *less* attention
compared to every other code in Debian. My only motivation to package
it was since it was *once* used by colleagues of mine. This is not the
case any more so I'm simply doing my maintainers maintenance duty. In
any case I appreciate if somebody else (upstream or some other
interested party) wants to do some more and I'd love to provide help to
do so. But as long as upstream does not even mind to notify us about
their release model I think there is no big need for action from my
side.
> > Thanks. We definitely need your help to find out whether libarb can build
> > SINA.
> I'll look into it. Where can I find the packages?
As I said: Precompiled packages for your comfort are here:
https://people.debian.org/~tille/packages/libarb/
For sure you can also build yourself from
https://salsa.debian.org/med-team/libarb
Any other hint you might need to answer item 2. from above?
Kind regards
Andreas.
[1] http://download.arb-home.de/special/manual-builds/2018_10_19/
--
http://fam-tille.de
Reply to: