Hi Andreas, Le 09/04/2020 à 23:01, Andreas Tille a écrit : >> >> 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? >
I have been getting in touch with upstream, who wish to postpone this task until they have more time to care for it. After we exchanged emails, they have published new versions of sumalibs, sumatra and sumaclust with my patch proposal for a regression I observed last week, but they reintegrated the sumalibs directory in sumaclust and sumatra: now sumalibs is present three times in their repositories. When I packaged them, I removed the directory from sumaclust and sumatra, adding ``+ds'' to the upstream version number. > >> 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. > I have used CMake to package sumalibs in the way you did with libsmithwaterman. I have split it into libsuma1 which holds the shared library, and libsuma-dev which holds the static library and the symlink to the shared one. Besides: * I have used .install files for the libs in sumalibs, and put a .symbols file for libsuma1; * I have added a test, which builds and runs a simple program, for libsuma-dev, and provided it for autopkgtest and as an example; * sumaclust and sumatra now rely on libsuma1; * sumatra now has tests, written for autopkgtest and provided as examples. If you have time, I would appreciate a review of the three packages, which are in their three Salsa repositories. https://salsa.debian.org/med-team/sumaclust/ https://salsa.debian.org/med-team/sumatra https://salsa.debian.org/med-team/sumalibs > > Kind regards > > Andreas. > Thanks and have a nice evening, Pierre
