> On Dec 1, 2016, at 17:39, Sean Farley <s...@farley.io> wrote:
>>> 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.
> Then I don't think zstd is ready to be used. If it's not ready, then
> it's not ready. I'm a bit sad but unless I can link with the system
> provided zstd, then this is a no-go for me.

Noted. That seems like a reasonable position.

>>> 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 fine.
> I'm afraid I'll have to do that. I'm a bit worried with how fast this
> was pushed through and how many other distros will turn off zstd.

For what (little) it's worth, you're the only maintainer I've heard from that 
has a problem with this. I hope you'll reconsider in the name of IO speed, but 
realistically I don't think it'll matter soon (given that I expect the zstd 
people to finish their API.)

Excluding zstd from your packages is totally fine: that's why we made it 
possible (and if it's not, that's strictly a bug IMO, and is something I'll 
gladly take patches for.)
Mercurial-packaging mailing list

Reply via email to