[Rpm-maint] better way to port packages to new architectures

Kamil Dudka kdudka at redhat.com
Sun Apr 7 00:43:22 UTC 2013


On Friday, April 05, 2013 20:43:33 Panu Matilainen wrote:
> On 04/05/2013 04:06 PM, Kamil Dudka wrote:
> > Hi RPM hackers,
> > 
> > Dennis Gilmore routed me to this mailing-list with my question.  In order
> > to> 
> > fix the following bugs:
> >      https://bugzilla.redhat.com/show_bug.cgi?id=924967
> >      https://bugzilla.redhat.com/show_bug.cgi?id=925048
> > 
> > ... I asked upstream to use autoconf-2.69+ for making the tarballs from
> > now
> > 
> > on and got an interesting answer:
> >      http://lists.nongnu.org/archive/html/acl-devel/2013-04/msg00003.html
> 
> "seems Redhat is "just" discovering this problem because they never
> really ventured outside the realm of the safe big iron world before."
> 
> That's pretty funny :) The %configure version in redhat-rpm-config
> started copying updated config.{sub,guess} into place about the time
> Gentoo released their 1.0 version back in early 2002:
> http://git.fedorahosted.org/cgit/redhat-rpm-config/commit/?id=0a68ef9360bc52
> f57cabbd90bc5deb8fd502b37e
> 
> That is, until it got rather unceremoniously dropped here, without much
> in the way of explanation:
> http://git.fedorahosted.org/cgit/redhat-rpm-config/commit/?id=9ed9b4e3459e31
> 25befd324f579f751a239c26ca

While it might be interesting to investigate whose idea it was, I am more 
concerned about the current situation in Fedora.  We are asking maintainers
to manually patch spec files over and over to fix issues that can be fixed
in a generic way instead.

> > The problem is that the recommended solution (asking upstream to use a
> > newer autoconf) is a one-shot solution.  It needs to be done per each
> > single package and it will need to be done again when we decide to
> > support yet another architecture.
> > 
> > Running autoreconf during build (the 2nd recommended solution) is
> > error-prone. It can easily pull in bugs that do not exist in the upstream
> > tarballs, which themselves are extensively tested before they are
> > declared stable.  You can> 
> > take the following bug as an example:
> >      https://bugzilla.redhat.com/show_bug.cgi?id=669048
> > 
> > Gentoo maintains a simple package sys-devel/gnuconfig that contains only
> > config.{sub,guess}, which are used to replace the files provided in the
> > upstream tarballs by their build system.
> > Could you please consider using a similar approach for RPM?
> 
> I dont mind adding such a thing (back) to %configure if that's what
> auto*foo upstream recommends. If we can agree on a cross-distro method,
> all the better. I guess the real question would be, where to copy the
> config.foo from?

Preferably from a package that takes updating config.{sub,guess} seriously.

> At least on Fedora, libtool has one copy, automake has another, and
> redhat-rpm-config used to (hmm, actually still does) carry its own copy
> which in turn is copied from libtool at build time. Oh and then
> rpm-build carries its own copies (something I didn't even remember) in
> /usr/lib/rpm/config.*, which are copies of its own config.* files that
> AFAIK nothing actually uses. Quite hilarious. Or hysterical.

On my rawhide box, the config.sub from rpm-build and automake-1.13 seem
to support aarch64 already whereas the ones provided by libtool,
redhat-rpm-config, and older automakes do not.

The autoconf package installs the config.{sub,guess}.1 man page but no
config.{sub,guess} -- is that intentionally?

Kamil


More information about the Rpm-maint mailing list