[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: libmurmurhash 1.3

Hi Andreas,

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
lintian error.
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.“ [1] 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.


1: https://cre.fm/cre209-das-linux-system?t=15:53

Reply to: