Re: [Acl-devel] update to autoconf 2.69

[Kamil Dudka]

On Thursday 04 April 2013 07:04:57 Mike Frysinger wrote:
> On Wednesday 03 April 2013 16:42:34 Jan Engelhardt wrote:
> > On Wednesday 2013-04-03 17:33, Mike Frysinger wrote:
> > >On Wednesday 03 April 2013 09:52:18 Kamil Dudka wrote:
> > >> would it be possible to use autoconf 2.69+ for creating the new
> > >> releases of attr and acl in order to support the ARM 64 bit CPU
> > >> architecture (aarch64)?
> > >>
> > >> We have the following bug reports in Fedora:
> > >>
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=924967
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=925048
> > >
> > >you guys are "fixing" your packages the wrong way.  you should improve
> > > rpm to automatically update config.{sub,guess} files with the latest
> > > ones. we've done this for years in Gentoo
> >
> > The same topic has come up in openSUSE,
> > http://lists.opensuse.org/opensuse-factory/2013-03/msg00274.html
> 
> that's pretty much what we do in Gentoo.  i periodically make a snapshot of
> the latest GNU config git tree and have a package called
>  sys-devel/gnuconfig. our automake & libtool packages (*not* autoconf btw
>  as this has nothing to do with autoconf or its 2.69 release) then symlink
>  their local copies of config. {sub,guess} to the gnuconfig versions.  thus
>  updating just the gnuconfig package means anyone using autotools on Gentoo
>  automatically include the latest regardless of the autotool version they
>  pick.
> 
> for ebuilds, portage takes care of replacing all local copies of config.
> {sub,guess} in the source tree with the latest & up-to-date ones installed
>  by the system gnuconfig package.
> 
> seems Redhat is "just" discovering this problem because they never really
> ventured outside the realm of the safe big iron world before.  so all the
>  cpus they targeted have long been in config.{sub,guess}.
> 
> if us distro peeps could agree upon a convention for where to install these
> files (i picked /usr/share/gnuconfig/config.{sub,guess}), i wonder if we
>  could convince the upstream GNU config project to add automatic re-exec
>  support to their code ...  i.e. the first thing the script would do is
>  extract the timestamp= field from /usr/share/gnuconfig/${0##*/} and if it
>  was newer than the current timestamp field, it would execute that version
>  instead.  then in a year or two, this would resolve itself automatically
>  (even when building software outside of the package manager).

Thank you for sharing your experiences!  I have notified RPM folks about it:

http://lists.rpm.org/pipermail/rpm-maint/2013-April/003528.html

Kamil