On Thu, 2013-05-30 at 11:56 +0100, David Woodhouse wrote: > We had a local copy of the LZX decompression code, taken from libmspack > and then hacked up somewhat to support the variant that the EWS GAL > uses. I cleaned up that code and got it accepted into upstream > libmspack, and libmspack 0.4 has been released a week or two ago. > > As part of that process, the libmspack maintainer spotted a number of > bugs in our changes. These have all been fixed in the 0.4 release. > > I've fixed the build in master so that we either need to build with > libmspack 0.4 as an additional dependency (recommended), or use a > configure option to build with our internal version of the decompression > code instead. If you configure without an appropriate libmspack, the > resulting error will tell you about the --with-internal-lzx option.
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. We're giving special attention to the stable release this cycle, so I'm willing to bend the rules a bit. +1 from me. I think we could remove the internal lzx copy as early as 3.11. Matt _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
