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
Andreas.
> 1: https://cre.fm/cre209-das-linux-system?t=15:53
--
http://fam-tille.de
Reply to: