[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Using 'make dist' with a 32 UID
From: |
Finucane, Stephen |
Subject: |
RE: Using 'make dist' with a 32 UID |
Date: |
Mon, 5 Jan 2015 17:30:05 +0000 |
> 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?
>
> >
> > $ 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.
I will attempt to reproduce this issue on other Autotools-based packages and
report my findings.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org