[libvirt] [PATCH] Tell automake to use tar-pax instead of tar-v7 for make dist
Commit 66a04090673a5e21700d11bdea0084f1ee870c24 updated the API extention example patch series and added files that results in filenames longer than 99 chars during make dist. This is a problem because automake uses tar with the old v7 format during make dist. The v7 format is limited to 99 chars per filename. Use the newer and unlimited POSIX format instead. --- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index d942d3c..838dac7 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_MACRO_DIR([m4]) dnl Make automake keep quiet about wildcards & other GNUmake-isms -AM_INIT_AUTOMAKE([-Wno-portability]) +AM_INIT_AUTOMAKE([1.9 -Wno-portability tar-pax]) # Use the silent-rules feature when possible. m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])]) -- 1.7.0.4
On Wed, Oct 27, 2010 at 01:40:13PM +0200, Matthias Bolte wrote:
Commit 66a04090673a5e21700d11bdea0084f1ee870c24 updated the API extention example patch series and added files that results in filenames longer than 99 chars during make dist. This is a problem because automake uses tar with the old v7 format during make dist. The v7 format is limited to 99 chars per filename.
Use the newer and unlimited POSIX format instead. --- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac index d942d3c..838dac7 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_MACRO_DIR([m4]) dnl Make automake keep quiet about wildcards & other GNUmake-isms -AM_INIT_AUTOMAKE([-Wno-portability]) +AM_INIT_AUTOMAKE([1.9 -Wno-portability tar-pax])
# Use the silent-rules feature when possible. m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])])
ACK, does that fix the problem of the huge tarball being generated ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 10/27/2010 05:40 AM, Matthias Bolte wrote:
Commit 66a04090673a5e21700d11bdea0084f1ee870c24 updated the API extention example patch series and added files that results in filenames longer than 99 chars during make dist. This is a problem because automake uses tar with the old v7 format during make dist. The v7 format is limited to 99 chars per filename.
Use the newer and unlimited POSIX format instead.
NACK. The whole point of using the v7 format is to be more portable to more systems. Rather, we should fix the filenames to be shorter; I'm on that. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Wed, Oct 27, 2010 at 07:53:58AM -0600, Eric Blake wrote:
On 10/27/2010 05:40 AM, Matthias Bolte wrote:
Commit 66a04090673a5e21700d11bdea0084f1ee870c24 updated the API extention example patch series and added files that results in filenames longer than 99 chars during make dist. This is a problem because automake uses tar with the old v7 format during make dist. The v7 format is limited to 99 chars per filename.
Use the newer and unlimited POSIX format instead.
NACK. The whole point of using the v7 format is to be more portable to more systems. Rather, we should fix the filenames to be shorter; I'm on that.
What kind of systems don't support the newer POSIX formats ? Are there actually any that are new enough for us to care about with libvirt ? We're effectively only targetting OS that were released in the last 5 years, so either tar-pax or tar-ustar might be well enough supported for our needs REgards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 10/27/2010 08:10 AM, Daniel P. Berrange wrote:
Use the newer and unlimited POSIX format instead.
NACK. The whole point of using the v7 format is to be more portable to more systems. Rather, we should fix the filenames to be shorter; I'm on that.
What kind of systems don't support the newer POSIX formats ? Are there actually any that are new enough for us to care about with libvirt ? We're effectively only targetting OS that were released in the last 5 years, so either tar-pax or tar-ustar might be well enough supported for our needs
Per the automake manual: http://www.gnu.org/software/automake/manual/automake.html#Options
tar-v7 selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. When given longer file names some tar implementations will diagnose the problem while other will generate broken tarballs or use non-portable extensions. Furthermore, the V7 format cannot store empty directories. When using this format, consider using the filename-length-max=99 option to catch file names too long.
tar-ustar selects the ustar format defined by POSIX 1003.1-1988. This format is believed to be old enough to be portable. It fully supports empty directories. It can store file names with up to 256 characters, provided that the file name can be split at directory separator in two parts, first of them being at most 155 bytes long. So, in most cases the maximum file name length will be shorter than 256 characters. However you may run against broken tar implementations that incorrectly handle file names longer than 99 characters (please report them to bug-automake@gnu.org so we can document this accurately).
tar-pax selects the new pax interchange format defined by POSIX 1003.1-2001. It does not limit the length of file names. However, this format is very young and should probably be restricted to packages that target only very modern platforms. There are moves to change the pax format in an upward-compatible way, so this option may refer to a more recent version in the future.
tar-ustar might be acceptable, but tar-pax is too risky. But why even worry about it, when it is trivial to avoid the problem in the first place? https://www.redhat.com/archives/libvir-list/2010-October/msg01078.html -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Matthias Bolte