Re: RFS: libmurmurhash 1.3
Hi Fabian,
I had a look on the build logs[1] and at least mips and s390x keep
on failing (some archs are not yet build).
Sorry for keeping you busy with this
Andreas.
[1] https://buildd.debian.org/status/package.php?p=libmurmurhash
On Mon, Feb 11, 2019 at 05:28:32PM +0100, Andreas Tille wrote:
> 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
--
http://fam-tille.de
Reply to: