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

[Lumin <cdluminate@gmail.com>]

Hi Adam,

Thank you for reviewing this package!

Updated package was uploaded to mentors:
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

and debomatic:
http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

Changes:
* fixed the mistaken /lib/<multiarch-triplet>/libxxx.a install path.
The static library didn't drop
  sip_tree_hash.o object.
* patched upstream makefile to produce a shared object file
(sip_tree_hash.o is dropped from so file)
* added symbols control file
* override dh_auto_test to run upstream test binaries (except for the
"benchmark").

Is it acceptable now?
:-)

On 20 April 2017 at 16:08, Adam Borowski <kilobyte@angband.pl> wrote:
> 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!



-- 
Best,
Lumin