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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
