> 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
>>>> 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