[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:
> >>
> >> 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).
-mike
signature.asc
Description: This is a digitally signed message part.