Re: RFS: libmurmurhash 1.3
On 11.02.19 15:41, Andreas Tille wrote:
Furthermore, I added some man page links. I also wanted to remove
some private functions from the .symbols file. However, that resulted in a
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?
Got it; managed to define the PMurHash with visibility hidden. Will
create a new upstream version with bumped soname some time.
So my advise to upstream is:
1. Declare the private functions really private
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*)
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
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.