Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Adam Borowski <kilobyte@angband.pl>]

On Thu, Apr 20, 2017 at 10:35:41AM +0000, Lumin wrote:
>   I am looking for a sponsor for my package "highwayhash"
> 
>  * Package name    : highwayhash
>    Upstream Author : google
>  * URL             : https://github.com/google/highwayhash

>   It builds those binary packages:
> 
>     libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

You install the .a file into /lib, that's a place for important boot-time
shared libraries, not for stuff that's used only during compilation.

I see no shared library at all -- why do you provide only a static version? 
That's useful only for limited special uses, unfit for a general purpose
library.  Static libs might sort-of work for Google's internal projects, as
they have a centralized tightly managed infrastructure so "recompile world"
for every single bug fix is doable, but in a loose ecosystem such as a
distribution it's unfeasible.  You might get away with static libs if you
closely cooperate with all of your reverse dependencies, but that's
pointless for a library meant for wide use, such as hashes.

Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
an universal distibution.  The other two hashes provide portable versions
that work on every CPU of every arch, but as SipTreeHash gives a different
output, its inclusion is kind of pointless.


Your choices may differ, but I'd make the following changes:
* provide a shared library
* drop the static one -- or at least move it into the proper place
* disable SipTreeHash, as failing at compile time rather than runtime is
  nicer to users

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!