On Thu, 2013-05-30 at 07:41 -0400, Matthew Barnes wrote:
That's the right way. A two week-old release is far too new for a stable branch dependency, especially one we're introducing mid-stream. It needs to be optional for now, but at the same time we do want packagers to be aware of it. Aborting the configure script by default with a workaround message if libmspack 0.4 is not present accomplishes that.
(I know we care about more than just Fedora, but FWIW libmspack 0.4 is in updates-testing for Fedora 19 and the Fedora packages of evo-ews 3.8.3 should be built to use it, if we do go ahead and push this.)
We're giving special attention to the stable release this cycle, so I'm willing to bend the rules a bit. +1 from me.
Thanks. I'll wait to see if I've won Milan round, before doing so...
I think we could remove the internal lzx copy as early as 3.11.
Note that I'm actually thinking of *disabling* the incremental-update feature in the case where we're using the internal LZX code. It's all very well not bothering to check CRCs when we're just doing a simple decompression of the full file, but when we are applying multiple binary deltas starting from a file we found in our local cache from last time, we *really* ought to be checking the output more carefully. I'm not really sure that affects the question I actually asked about backporting to 3.8, either way; just reinforces the "you *really* ought to be using the proper library" assertion. And it means I'd prefer to remove the fallback before 3.10, rather than after it. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature