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

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

 



Am Montag, den 17.06.2013, 11:39 +0300 schrieb 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@xxxxxxxxxxxx                  http://users.actcom.co.il/~oron
> "In theory, there is no difference between theory and practice. In practice, there is."
>         -- Yogi Berra
> 

Hi Oron!

I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.

Cheers,
  Björn

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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux