Re: sumatra uploaded using Debian packaged sumalibs
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
Reply to: