> On Dec 1, 2016, at 17:29, Sean Farley <s...@farley.io> wrote:
> Augie Fackler <r...@durin42.com> writes:
>>> On Dec 1, 2016, at 17:07, Sean Farley <s...@farley.io> wrote:
>>> Augie Fackler <r...@durin42.com> writes:
>>>>> On Dec 1, 2016, at 08:53, Neal Becker <ndbeck...@gmail.com> wrote:
>>>>> Fedora guidelines: All packages whose upstreams allow them to be built 
>>>>> against system libraries must be built against system libraries.
>>>>> So if zstd could become a standard system library it would have to be 
>>>>> unbundled.
>>>> That should be possible some day, but today we're depending on an as-yet 
>>>> unstable API that requires static linking against a specific version of 
>>>> the library. Is that sufficient to prevent unbundling for now?
>>> Well, that's problematic for me since I've already added zstd as a
>>> system lib in MacPorts (under the, I believe, fair assumption) that this
>>> would be easy to override and link against.
>> It won't hurt anything to have it there, it just won't help you until zstd 
>> stabilizes their API and we can get on the stable API.
>> It was a fair assumption, except for all the discussion both here and on 
>> indygreg's patches which made it clear that it wasn't ;)
> I don't understand why there isn't a switch to enable this?

I'm not sure what "this" is - if "this" is "using zstd at all" then yes, I 
believe that's in there. If it's "using a system zstd instead of the vendored 
one" that's *technically infeasible* with the current stable zstd API. The wire 
format is stable, but the API is still under some amount of development and 
they're being careful.

> When I read
> the patches, I thought that was the goal? I'm a bit disappointed in this
> situation now and retract my support of vendoring zstd.

If it's that worrisome, have MacPorts ship hg without zstd - that'll always be 
Mercurial-packaging mailing list

Reply via email to