On Mon, Feb 11, 2019 at 04:53:16PM +0100, Fabian Klötzl wrote: > > Could you be more verbose about what you did and what lintian error was > > issued? Normally you do not simply remove symbols vrom the .symbols > > file manually. You should rather declare the interface private inside > > the code and update the symbols file. > > Long Description: PMurHash comes with a few functions e.g. > "PMurHash32_Process" which I use internally, but I don't want to support. > The true API of libmurmurhash consists of six functions "prefixed with lmmh_ > or MurmurHash3_. Only these functions appear in the header supplied by the > -dev package. As they are the public interface, only they should appear in > the symbols file, right? > > > So my advise to upstream is: > > > > 1. Declare the private functions really private > Got it; managed to define the PMurHash with visibility hidden. Will create a > new upstream version with bumped soname some time.
:-) > > 2. Use Automake > > I leave it to Lennart Poettering to describe the madness that are the > autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein > Shellskript generiert, was ein Makefile generiert.“  Even though I know > automake, I am a bit reluctant to add it to libmurmurhash, because I think > that for such a small project a simple makefile should suffice. (And it > works just fine on Arch Linux *cough*) You try to use the method "proof by authority" to make your point? ;-P Well, I did not added the patch since I have to much spare time. As far as I remember your package had three issues: 1. No multiarch triplet installation 2. Static lib in wrong place. 3. No pkg-config support So I had the choice to move things around manually to use d-shlibs or to write some Makefile creating system. I'm less educated with cmake thus I cut-n-pasted some existing automake patches we have for other libs. The point is that you need to write only a few lines of code to solve all three issues above and in the end it might help other distributors as well. If you prefer cmake (or whatever you authority suggest ;-)) that's perfectly fine for me. To quote another authority: "Everything should be made as simple as possible, but not simpler." (A. Einstein) I regard the simple Makefile as to simple for the intended purpose. > > 3. Bump SONAME if the resulting lib has changed / removed symbols > > > > Please note: Bumping SONAME also means changing the package name and > > thus trying another round inside new queue. While currently ftpmaster > > is incredibly quick I've seen relion sitting there for longer than > > expected due to the same reason (admittedly way more complex code to > > review). In any case the tour via new queue has a non-predictable delay > > time and may be we wait until mash has migrated to testing before doing > > this. > > Fully agree on this one; Let's take one step after the other, first > libmurmurhash, then mash, then our other packages, and, maybe if we want to > and the API/ABI is stable, other debian packages. Fine. So we have some time to decide. Kind regards and thanks a lot for your work on that lib in any case Andreas. > 1: https://cre.fm/cre209-das-linux-system?t=15:53 -- http://fam-tille.de