rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Oron Peled]

On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
> Hi,
> I'm trying follow this (aarch64 support) but
> https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
> 
> "could/should be closed now, as this is done automatically from %
> configure", so no need update it anymore ?
> 
> we had updated dpkg some major versions sine bug opened, how I know if
> dpkg is now ready for aarch64 ?

When I fixed one of my packages (libhocr), I chose a different fix:
  * Added: BuildRequires: autoconf, automake, libtool, pkgconfig
  * In "%prep" added: autoreconf --install --force

IMO this is better then the new rpm kludge:
  * In autotools based projects, the tarball contain *many* generated files.
     (e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}

  * The only reason they are in the tarball is to enable build without
     the autotools suite (e.g: on other platforms)

  * As such, these files are not [and should not be] committed to version
    control systems.

  * So although they are packages in the source  tarball, they are no
     part of the package real "source" -- they just happen to
     come from the platform of the one who maintain the source tarball.
     (via "make dist")

  * The "autoreconf" solution let autotools handle this complete problem
     without trying to mess in its internals (rpm replacing only some files).

  * As an example how wrong it is for rpm macros to interfere with the
    internal logic of autotools, you could have a look in %GNUconfigure
    macro in /usr/lib/rpm/macros. This one, tries to second guess
    autoconf behavior, but it still search for "configure.in" files.
    (For those who don't know -- while these files are still supported,
     most modern packages correctly renamed them to "configure.ac").

In the Fedora spirit of "everything buildable from clean sources", I think
the "autoreconf" solution should be globally adopted (regardless of aarch64):
  * It doesn't use generated files as input to the build process.
  * It delegates the actual management to where it belongs.

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"In theory, there is no difference between theory and practice. In practice, there is."
        -- Yogi Berra