On Wed, Jun 15, 2016 at 01:25:35PM +0200, Michal Privoznik wrote:
On 13.06.2016 11:46, Andrea Bolognani wrote:
> On Mon, 2016-06-13 at 09:57 +0100, Daniel P. Berrange wrote:
>>> Since RHEL5 support has been dropped for a while now, maybe it's time
to
>>> revisit changing the tar format
>>
>> Yep, IIUC we should be fine for require pax support for the vintage of
>> Linux we required. *BSD should be fine too, so IIUC, their tar version
>> uses libarchive which supports pax. Windows has 7-zip which can do pax
>> and of course cygwin. Finally OS-X has the pax command and support in
>> the apple archive utility.
>>
>> So I think we're be fine to require it.
>>
>> While, we're changing this, I think we should probably take the opportunity
>> to also switch over to using 'xz' as our compression format, instead of
gz.
>> Consider the 1.3.5 release compressed with different formats:
>>
>> 35109092 libvirt-1.3.5.tar.gz
>> 25573966 libvirt-1.3.5.tar.bz2
>> 12112612 libvirt-1.3.5.tar.xz
>>
>> Those results seem pretty compelling to me :-)
>
> xz compression sure takes a lot of time!
Maybe it does, but it's done just once, while decompression is done
multiple times. So I think we can switch to xz. In fact, I'd be okay
with nothing but xz.
But will this solve the issue? I mean, the problem that Cole is seeing
(and I'm too) with too long path names. Isn't tar the origin of it?
Because if it is, I fear that changing compression algorithm won't help
much.
We already agreed that we should switch to the pax format, I'm just
saying, we should *also* switch to xz compression.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|