Re: Using 'make dist' with a 32 UID

[Eric Blake]

On 01/05/2015 10:30 AM, Finucane, Stephen wrote:
>> On 01/05/2015 03:08 AM, Finucane, Stephen wrote:
>>> Autotools defaults to the 'v7' legacy tar format in GNU tar, through
>> passing of the '-o' parameter to GNU tar. Enabling this option results in
>> errors for users with 32 bit UIDs. For example, with the Open vSwitch
>> package:
>>
>> 'make dist' is under the purview of automake, not autoconf.  You may get
>> a better response by involving the automake list.
> 
> Sorry - I find the line between the two to be rather blurred at the best of 
> times :) Should I forward this or CC this list?

I've added the automake list in cc (I'm interested enough in the outcome
that I don't mind if the autoconf list remains in the distribution).

> 
>>
>>>
>>>     $ make dist
>>>     ...
>>>     tardir=openvswitch-2.3.90 && ${TAR-tar} chof - "$tardir" | GZIP=--
>> best gzip -c >openvswitch-2.3.90.tar.gz
>>>     tar: value 12345678 out of uid_t range 0..2097151
>>>     tar: Exiting with failure status due to previous errors
>>>     make[1]: Leaving directory `/development/ovs'
>>>     ...
>>>
>>> I managed to modify the Autoconf 'configure.ac' file to use the 'tar-
>> ustar' format, which allow longer file names and other niceties. Again,
>> with the Open vSwitch package:
>>>
>>>     diff --git a/configure.ac b/configure.ac
>>>     index ebb8b02..6505189 100644
>>>     --- a/configure.ac
>>>     +++ b/configure.ac
>>>     @@ -19,7 +19,7 @@ AC_CONFIG_MACRO_DIR([m4])
>>>      AC_CONFIG_AUX_DIR([build-aux])
>>>      AC_CONFIG_HEADERS([config.h])
>>>      AC_CONFIG_TESTDIR([tests])
>>>     -AM_INIT_AUTOMAKE
>>>     +AM_INIT_AUTOMAKE([tar-ustar])
>>
>> Are you proposing that we change the way autoconf is distributed?  That
>> won't affect any other packages (you'd have to make the same patch for
>> each affected package), and so far, your code shows that you had
>> problems in building an openvswitch tarball, not an autoconf tarball.
>> Again, changing automake to do this automatically for ALL packages (once
>> those packages are built with a new enough automake) rather than trying
>> to patch one configure.ac for every affected package, seems like it
>> would be the better course of action.
>>
>> I'm still open to be convinced that autoconf needs to alter its own
>> configure.ac, but I don't have enough evidence yet that it would make a
>> difference.
> 
> Not necessarily. The use of the 'v7' format means any users with a 32 bit UID 
> will need to modify every 'configure.ac' file they come across to fix the 
> above issue. However, it's not like I personally work with enough packages to 
> make this much of an issue. Instead, an approach that would allow me to 
> enable the 'tar-ustar' format dynamically (like the 'configure' option above) 
> would be just fine, if such a thing exists. This would allow me (and all 
> 32bit UID users) to adopt a standard approach to working with Autotools based 
> packages (i.e. always pass an option to the 'configure' script of any 
> Autotools-based package).
> 
> Changing the default tar format used by Autotools would result in a permanent 
> fix for all affected users, as you say (affected users = the other developers 
> in my team in Intel, for example). However, I don't know if this would cause 
> compatibility issues on certain (very, very old) machines. You could see a 
> scenario whereby the 'make dist' target of (previously working) 
> autogenerated-Makefiles files would break when Autotools is updated, due to 
> the ustar format not being supported. I have no data on tar ustar support, 
> I'm afraid.

As for whether the upstream automake should make it easier for runtime
overrides of the format, or even dynamic changes, I am not sure.  I also
know that some packages (particularly those using gnulib's GNUmakefile)
explicitly set:

export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner

to try and avoid the problem of a 32-bit uid interfering with the
creation of old-style tar files.  Maybe that is an approach that should
be folded into automake?

> 
> I will attempt to reproduce this issue on other Autotools-based packages and 
> report my findings.
> 

Not sure that your additional testing will change anything - again, the
issue here is that automake would be the one place to change for
everyone else to automatically benefit from, once packages are rebuilt
with newer automake.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature