[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Acl-devel] update to autoconf 2.69

From: Mike Frysinger
Subject: Re: [Acl-devel] update to autoconf 2.69
Date: Thu, 4 Apr 2013 01:04:57 -0400
User-agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; )

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:
> >> 
> >>
> >>
> >
> >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,

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 
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 
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).

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]