[libvirt] Bump tar format?

[Cole Robinson]

This issue appeared again:

tar:
libvirt-1.3.6/tests/virhostcpudata/linux-deconf-cpus/node/node17/cpu136/topology/thread_siblings_list:
link name is too long; not dumped
tar:
libvirt-1.3.6/tests/virhostcpudata/linux-deconf-cpus/node/node17/cpu128/topology/thread_siblings_list:
link name is too long; not dumped
tar:
libvirt-1.3.6/tests/virhostcpudata/linux-deconf-cpus/node/node17/cpu120/topology/thread_siblings_list:
link name is too long; not dumped
tar:
libvirt-1.3.6/tests/virhostcpudata/linux-deconf-cpus/node/node16/cpu112/topology/thread_siblings_list:
link name is too long; not dumped
tar:
libvirt-1.3.6/tests/virhostcpudata/linux-deconf-cpus/node/node16/cpu104/topology/thread_siblings_list:
link name is too long; not dumped

Affects fedora 23 but not fedora 24 for whatever reason

On 07/22/2015 11:57 AM, Eric Blake wrote:
> On 07/22/2015 08:44 AM, Andrea Bolognani wrote:
>>   1. rename the test case, making it shorter;
> 
> Works if we can do it, but I agree we should add a syntax check to
> enforce it.
> 
>>
>>   2. bump tar format from ustar, which has limitations on the length
>>      of file names, to posix/pax, which has no such limitations.
> 
> Might be doable, if RHEL 5 autoconf/automake/tar supports it.  Here's
> where we switched to ustar:
> https://www.redhat.com/archives/libvir-list/2012-April/msg01435.html
> commit 75ad8b67
> 
> and even then, we ran into problems with too-long symlinks (which are
> processed differently than regular files).

Since RHEL5 support has been dropped for a while now, maybe it's time to
revisit changing the tar format

- Cole