Hi Pierre, On Thu, Apr 09, 2020 at 03:52:10PM +0200, Pierre Gruet wrote: > > Yes, I noticed that sumalibs was accepted; I will happily take over the > maintenance effort for those three packages!
Very nice. > > I think an open todo > > item would be to remove the sumalibs code copy from sumaclust and > > build both, sumaclust and sumatry, against the same lib. > > > > Let me know what you think. > > I remember you evoked it a few days ago, and I have thought about it since > then. I am now looking at the changes you did today on sumalibs and sumatra. > > My question is: as I understand /4.13 Embedded code copies/ in the Debian > policy, sumatra and sumaclust should use the libs in sumalibs to build, but > the code of those libs that is duplicated inside sumaclust should remain > there (and not be used), right? Well, I prefer to remove what is not used - just to make sure its really not used. The suma* packages are also inconsistent from upstream side: sumaclust included sumalibs but sumatra does not include it. May be this issue can be tackled from upstream to exlude it consistently? > Furthermore, currently sumalibs provides a static library built by > upstream's Makefiles, should we try to move to a shared library or should we > instead not differ from upstream on that? Debian usually provides shared *and* static lib. This can be easily approached by a more modern build system than plain Makefile (automake - not really modern but anyway, cmake, meson, ...) I once had added automake to some lib to approach this: https://salsa.debian.org/med-team/libsmithwaterman/-/blob/master/debian/patches/autoconf.patch Its not that I personally love autoconf - I just found an example of it and in all the years of Debian I gathered the most experience with this. This should be no advise to use autoconf here. Kind regards Andreas. -- http://fam-tille.de
