GNOME Bugzilla – Bug 659404
lzma compression support
Last modified: 2012-01-27 14:26:02 UTC
Created attachment 196885 [details] [review] libxml2-add-lzma-compression-support.patch This patch adds liblzma support, next to the libz support... When enabled, libxml can now handle lzma/xz compression too. It's somewhat complicated by the missing "xzopen" interface, and by transparently handling gzip even when lzma is enabled.
Created attachment 196902 [details] [review] libxml2-liblzma.patch I cleaned the support up by moving helpers to separate file, and added the missing API entry needed for XML_WITH_LZMA...
Okay, I finally came around reading this, sorry for the delay. This is a bit scary, I mean it's a lot of code, I got a bit better when I discovered it was in a large part based on alone_decoder.c from the xz project code. There is still a few things I worry about like in xz_state, the lzma_stream and z_stream structures are embbeded in. This create a serious risk, if the libraries are upgrated, and somehow they change the structures, libvirt will suddenly crash. Yes libraries are not supposed to break ABIs, in practice this happens all the time, and I'm cautious. I would very much prefer using an allocator/deallocator from the library if this exists instead. ... okay read a bit of doc "Passing data to and from liblzma" and it seems that they really expect us to allocate that structure it's weird... I think the new xzlib.c will need a header with author etc.. and go though indent(1) to match existing libxml2 code. but that's something I can do... Will look for possible feedback on your side before pushing this in any case thanks, Daniel
I think the original idea upstream was to provide a stream-oriented library (called ) that would handle the *zfile scenario, without downstream duplication. "A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API." But that library is not done (started?) So I made an internal (read-only) implementation of such a library for .lzma and .xz, but it would probably be better if it was handled externally... But maybe it could be made more resistant to change in the libz and liblzma libraries and their headers/structures, without being "pushed out" into an external library ?
Okay, sorry it took so long, but the good news is that I used some of the chinese new year vacations to finish the patches cleanup and push. This is now integrated upstream in the head branch ! W.r.t. making a separate library, I don't think that would be a great idea as it would make the dependancy chain even more complex, so your approach is probably better. Check out the git, and see if I added any mistake ! :) Daniel