[Rpm-maint] [draft] spec file unification: autotools based projects

[Stanislav Brabec]

Hans de Goede wrote:
> Ralf Corsepius wrote:
> > On Thu, 2008-07-17 at 17:09 +0200, Stanislav Brabec wrote:
> >> Hallo.
> >>
> > 
> >> %build
> >>
> >> Packagers are encouraged to call autoreconf whenever possible. It
> >> guarantees correct build of packages on platforms, that was not
> >> supported by autotools in the time of the source release.
> >>
> >> autoreconf -f -i
> > 
> > I vehmently disagree, because this contradicts the autotools' working
> > principles: The autotools are not supposed to be run during building a
> > package. The files they generate are supposed to be shipped as part of
> > the tarball.
> > 
> > In practice, your recommendation is causing massive problems and is
> > harmful on many occasions, esp. with improperly implemented
> > auto*sources.
> > 
> 
> I agree, blindly calling autoreconf is BAD really really BAD (take it from 
> someone who maintanis 200 packages). Often the autoreconf input files were 
> written for different versions of autofoo then are available in the buildsys, 
> also as Ralf says this goes against the design principles of autofoo. I've 
> often taken over packages from other people, and removed calling autoreconf and 
> instead patch both the .am and .in manually (so that if autoreconf ever gets 
> called again the patch sticks around), fixing many bugs that way.
> 
> Calling autoreconf more often _causes_ problems then that it solves them. If a 
> package _needs_ an autoreconf for bugfixes in newer autofoo versions, upstream 
> is the place todo this, not during package build!

Well, we are in a different situation. For people preparing packages for
i586 and x86_64, there is no benefit for calling autoreconf: Fix nearly
never happens (as most developers use ix86 for testing), fixing
not-working autoreconf needs some work and it even rarely causes
breakage.

If you are building packages for platforms like s390x, ppc64 or iwmmxt,
the situation is exactly reverse:
Without calling autoreconf, many packages fail to build shared libraries
or fail on obscure errors. Calling autoreconf and porting it to the
latest autotools is far the simplest solution here.


1) We can define different rules for caling autoreconf:

- If you decide to call autoreconf in your spec file, you should verify
that it works with the latest autotools suite.

- Patching auto-generated files in %prep phase is not recommended. If
you need to modify auto-generated configure script, modify its source
instead and call autoreconf.

2) We can provide less invasive technique. I openSUSE, it is
%suse_update_config and %suse_update_libdir:

# %{suse_update_config [-fcl] [dirs...]}
#   -f: force, ignore timestamp
#   -c: no config.guess,config.sub
#   -l: no ltconfig,ltmain.sh
%suse_update_config(fcl) \
    AUTOMAKE_DIR=/usr/share/automake \
    [ -d $AUTOMAKE_DIR ] || AUTOMAKE_DIR=/usr/share/automake* \
    %{!-c:\
      [ -d $AUTOMAKE_DIR ] || { \
        echo 'Please, install automake.' \
        exit 1 \
      } \
    } \
    for d in . %{?*}; do \
      %{!-c:\
        for f in config.sub config.guess; do \
          if test -f $d/$f -a ! $d/$f -ef $AUTOMAKE_DIR/$f ; then \
            %{!-f:[ $d/$f -nt $AUTOMAKE_DIR/$f ] ||} cp -f $AUTOMAKE_DIR/$f $d/$f \
          fi \
	  if test -d $d -a ! -f $d/depcomp -a -f $AUTOMAKE_DIR/depcomp ; then \
	    cp -f $AUTOMAKE_DIR/depcomp $d/depcomp \
	    echo "please add depcomp to sources for new automake!" \
	  fi \
	  if test -f $d/missing -a ! $d/missing -ef $AUTOMAKE_DIR/missing ; then \
	     cp -f $AUTOMAKE_DIR/missing $d/missing \
	  fi \
        done \
      } \
      %{!-l:\
        for f in ltconfig ltmain.sh; do \
          if test -f $d/$f; then \
	    sed 's/linux-gnu\\([^*][^*]*\\)\\*/linux*\\1*/g; s/linux-gnu/linux/g; s,/lib\\\>,/%_lib,g; s,/%_lib\\([\$-]\\),/lib\\1,g' $d/$f > $d/$f-$$ && \
	    mv -f $d/$f-$$ $d/$f \
	    chmod +x $d/$f \
          fi \
        done \
      } \
    done \


%suse_update_libdir() \
   if [ %_lib != lib ]; then \
     for file in %{?*} ; do \
        [ ! -e $file ] && echo "Error:  $file does not exist!" && exit -1 \
        [ -e $file.nolib64 ] && echo "Error:  $file.nolib64 already exists!" && exit -1 \
        cp $file $file.nolib64 \
        echo "patching $file" \
        sed -e "s,/lib\\\>,/%_lib,g" $file.nolib64 | sed -e "s,/%_lib/cpp,/lib/cpp,; s,/usr/%_lib/perl,/usr/lib/perl, ; s,/%_lib\\([\$-]\\),/lib\\1,g" > $file \
        rm -f $file.nolib64 \
     done; \
   fi ; \


-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/