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

Re: RFS: libmurmurhash 1.3

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.“ [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*)

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

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


Reply to: