On Wed, Apr 21, 2004, Karl Vogel wrote:
> There is a subtle bug in the perl.spec file, which you only hit if you use
> rpm -bc --short-circuit. The Configure shell script of perl creates a file
> called 'config.sh' which is the equivalent of the autoconf config.cache
> file. If you change the parameters on the Configure line, you *MUST* remove
> the config.sh file or it will not use the new values!
>
> I think it is in everyone's interest that the %build part removes the
> config.sh file before issuing the Configure command. Normal users won't
> notice a difference, but openpkg developers will be grateful!
>
> [...]
> + rm -f config.sh
> ./Configure \
> -d -e -s \
> -Dprefix=%{l_prefix} \
> [...]
Your want that running a RPM section should be side-effect free, so it
can be repeated without problems. And all this even after changing the
section script itself between the runs. This certainly would be a very
useful property, but currently does not hold in 95% of all cases.
Most packages use Autoconf and there, with config.cache and other
on-the-fly generated files, a similar problem exists. So really a lot
of package patching (for cleaning up the implicit side-effect sources)
would have to be done in a similar fashion. I'm not sure whether it is
worth the effort, because here we also have to balance the additional
(more or less intrusive) hacks against the benefits we receive.
If we really want do this, I think the better approach would be to
shadow "./configure" and similar calls with more %{l_configure} and
corresponding macros and then place those "cleanup residues" commands
into these macro. This way you can avoid having to bump up hundrets of
package specifications with "rm" commands and at the same time have the
possibility to solve another issue: configure sometimes breaks with the
/bin/sh of more esoteric platforms. Then %{l_configure} can expand to
"%{l_bash} ./configure", too.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
