Bug 83060 - unnecessary automake14 dependency and autoreconf run
Summary: unnecessary automake14 dependency and autoreconf run
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: libtool
Version: 1.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Daniel Reed
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-29 21:40 UTC by Peter Backes
Modified: 2007-04-18 16:50 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-08 21:12:27 UTC
Embargoed:


Attachments (Terms of Use)
Proposed fix for the problem (2.45 KB, patch)
2003-01-29 21:43 UTC, Peter Backes
no flags Details | Diff
Patch for the spec file to use the modified bootstrap script (1.44 KB, patch)
2003-09-27 19:19 UTC, Peter Backes
no flags Details | Diff
Patch to make bootstrap leave the tree in a distributable state (621 bytes, patch)
2003-09-27 19:22 UTC, Peter Backes
no flags Details | Diff

Description Peter Backes 2003-01-29 21:40:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
The spec file for libtool buildrequires automake14 and runs autoreconf although
that would only be needed on x86_64, s390 or s390 architecture (because there
are patches being applied for them which need autoreconf to be run) or if
%_without_check is off.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Log in for example on i386 with %_without_check turned off in ~/.rpmmacros
2. rpm --rebuild libtool-*.src.rpm 
    

Actual Results:  error: failed build dependencies:
        automake14 is needed by libtool-1.4.3-4


Expected Results:  Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.17563
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf libtool-1.4.3
...

Additional info:

Comment 1 Peter Backes 2003-01-29 21:43:59 UTC
Created attachment 89691 [details]
Proposed fix for the problem

Comment 2 Jens Petersen 2003-01-30 01:35:29 UTC
You might be right, but is the dependence on automake14 such a big problem?
Autotools dependencies are complicated, with current patches ac-local needs
to be run anyway, so it seems safer to use aclocal-1.4 (or aclocal-1.5 at
least).

Comment 3 Peter Backes 2003-01-30 19:30:45 UTC
As far as I understand there are generally four classes of people that get in
touch with a program: developers, distribution vendors/package builders, system
administrators and users.  I have the feeling that build dependence on
auto*/libtool is like requiring a system administrator to install a compiler
just to modify the system configuration.

That means I think it would be great if such dependencies could be avoided for
packages at all means, especially for the auto*/libtool packages themselves (if
libtool needed automake, and maybe automake needed libtool that surely wouldn't
be good).  Isn't auto*/libtool meant to *facilitate* the build process and to
avoid complications?  Wasn't it designed to allow someone who wants to build the
package from source to do so without much trouble and especially without
installing extra packages like auto*/libtool (or several versions of them which
sadly seems to have become regular)?  auto*/libtool files should IMO really only
be patched (leading to auto*-buildrequire) if it's clear that the issue can't be
solved by moving the bug upstream.  

Have a look at the patch, it doesn't completely eliminate the automake
dependency.  But in those cases (on mainstream platforms and if tests are turned
off) where it's not really required, it makes the package build without
automake14.  

Comment 4 Jens Petersen 2003-05-01 14:43:19 UTC
The automake14 buildrequirement is gone in libtool-1.5-1,
though it still requires autoconf and automake to build because
of the autoreconf still present.

Comment 5 Peter Backes 2003-06-02 17:10:36 UTC
I have been waiting for one month now, yet I still cannot find libtool-1.5-1 on
the redhat ftp server in the rawhide directory.  I have thought about the whole
problem of auto*lation and I have some new ideas on how to avoid it, but I want
to check the new package first.


Comment 6 Peter Backes 2003-06-09 15:41:04 UTC
Okay, got the new package now.  Despite autoreconf being run, make still sees
something which it needs to run auto* for:

# rpm --rebuild libtool-1.5-2.src.rpm 
Installing libtool-1.5-2.src.rpm
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.15704
[...]
+ autoreconf
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.57331
[...]
+ ./configure [...]
[...]
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
+ make
rm -f acinclude.m4 acinclude.m4T
cat ./libtool.m4 > acinclude.m4T
mv acinclude.m4T acinclude.m4
cd . && /bin/sh /usr/src/redhat/BUILD/libtool-1.5/missing --run aclocal-1.7 
cd . && \
  /bin/sh /usr/src/redhat/BUILD/libtool-1.5/missing --run automake-1.7 --gnu 
Makefile
[...]


I had the idea to include an additional -derived patch instead of running
autoreconf to bring the derived files up to date.  But as long as the above
problem isn't solved, auto* would still be required.

Comment 7 Peter Backes 2003-09-27 19:13:17 UTC
I now figured out how these unnecessary auto* runs can be avoided.  See the
patches.  (And if you wish, you can now run rpm -bp and generate a diff from the
original patched version to the prepared BUILD/libtool* for the derivative files
so auto* is not required anymore.)

Comment 8 Peter Backes 2003-09-27 19:19:06 UTC
Created attachment 94784 [details]
Patch for the spec file to use the modified bootstrap script

Comment 9 Peter Backes 2003-09-27 19:22:52 UTC
Created attachment 94785 [details]
Patch to make bootstrap leave the tree in a distributable state

Comment 10 Daniel Reed 2004-10-08 21:12:27 UTC
The 1.5.10 release should not require any Red Hat patches, nor any
calls to any of the autotools. Due to the way the autotools are used
in our own build roots, I have been unable to upgrade our shipped
version to 1.5.10, but will attempt to do it the moment Fedore Core 3
has been released.


Note You need to log in before you can comment on or make changes to this bug.