[libvirt] Re: [PATCH] also allow use of XZ for Qemu image compression

[Jim Meyering]

Daniel Veillard wrote:
> On Wed, Sep 09, 2009 at 12:08:13PM +0200, Jim Meyering wrote:
>> Daniel Veillard wrote:
>>
>> > On Wed, Sep 09, 2009 at 11:57:40AM +0200, Jim Meyering wrote:
>> >> Daniel Veillard wrote:
>> >> >   Hum, I realize that support of LZOP was added after 0.7.0, so we never
>> >> > made a release with it (well except for git snapshot which may have been
>> >> > pushed).
>> >> >   I wonder if the best is not to just drop the lzop option altogether
>> >> > and stick xz as a package dependancy until we have found a way to
>> >> > provide at the API level which compression options are actually
>> >> > available.
>> >> >
>> >> >   Opinions ?
>> >>
>> >> Dropping lzop sounds good.  It seems lzop is not very popular.
>> >> We don't need that many choices.
>> >>
>> >> Maybe even nuke lzma too before we're stuck with it forever.
>> >> Technically, we can do that, since it was added only a month ago,
>> >> also after 0.7.0:
>> >>
>> >>   v0.7.0-35-g2d6a581
>> >
>> > Actually om my machine here lzma is provided as a backward compat option
>> > by xz, so yes I'm inclined to remove that option too:
>> >
>> > aphio:~ -> which lzma
>> > /usr/bin/lzma
>> > paphio:~ -> rpm -qf /usr/bin/lzma
>> > xz-lzma-compat-4.999.8-0.8.beta.20090817git.fc11.x86_64
>> >
>> > I will post a patch later,
>>
>> FYI, xz can decompress lzma-compressed input:
>>
>>   $ echo foooo |lzma -c|xz -dc
>>   foooo
>>
>> so libvirt won't need the "lzma" command, as long as xz is available.
>
>   Okay, I suggest the following patch removing the 2 extra compressors
> and making sure the package including the daemon, if compiled with qemu
> has the proper dependancies.
>   xz package dependancy is IMHO a small price to pay: Size: 443012
> to garantee reliability and bzip2 and gzip are so standard that it
> should not be a problem for anybody to list them explicitely.

The changes to the C code look fine to me.
However seeing the added dependency on xz makes me wish
for a "strongly-recommended" sort of tag, rather than
a hard dependency on a tool that one may never opt to use.

ACK, in spite of that.