There was an one-line mistake in the following comit. The dependency
on perl's name-version without release number could never been
satisfied.
commit fde8b38ed3
Author: Marcela Mašláňová <mmaslano@redhat.com>
Date: Mon Aug 13 14:05:08 2012 +0200
Define perl_compat by macro for rebuilds.
Sub-packages depend on compat rather than on nvr.
The dependencies are stored in gendep.macros file. The file be
regenerated from an RPM build log by ./generatedependencies tool.
The intended work flow is to build a new perl with RPM Perl dependency
generator available locally. Then use this ./generatedependencies tool to
convert the discovered dependencies into the gendep.macro file. Then it's
possible to build the new perl even without the RPM Perl dependency
generator available in the build root while the resulting binary
packages will still posses all dependencies.
The reason is standard perl-genererators is written in the Perl thus
perl-generators must run-require perl. Therefore there is
a build cycle. One could rewrite perl-generators.spec so that it did
not need perl for building, but the run-time dependency would still be
there.
One could claim the one run-time dependency can be satisfied by older
perl. And that's true and it has been done so until now. But that
would not solve the problem when bootrapping perl to a new architecture
or as an excercise the perl can be built without any prior perl
available (required by paranoid users). With pregenerated
dependencies, one can implement real bootstrap.
(Ultimate solution would be reimplement RPM Perl generators in C.)
We do not insert perl-ExtUtils-MM-Utils into perl-core because this is
not a core module. It's a Fedora extension.
Run regen/lib_cleanup.pl to regenerate Makefile.SH and other scripts
to pass porting/regen.t because of addedd ExtUtils/MakeMaker/MM/Utils.pm file.
But we add perl-ExtUtils-MakeMaker dependency on perl-devel beacuse
many XS package would fail to build. The dependency will be weaken
after proper announcement.
Expressing minimal Perl version as "perl >= 1:5.006" is insufficient:
The Perl version is defined by perl-libs, not perl.
Modules requiring specific Perl but no perl interpreter should not
pull in the perl package.
The epoch numbers are tedious to synchronize.
The auto-generated value is not normalized (1:5.006001).
After this change we will update perl-generators to produce
perl(:VERSION) dependency instead and we will rebuild perl and
perl-Exporter again to leverage this capability.
This is a temporary hack until we find the real cause. /usr/bin/perl
linked with -pie causes failures to:
perl-smartmatch-engine-core
perl-Algorithm-CurveFit
perl-B-Utils
perl-PDL-Graphics-PLplot
One could blame poor XS modules, but perl-Algorithm-CurveFit is
pure perl code with no XS modules. So the bug is somewhere in the
perl.
This is not needed since upstream commit:
commit adeb94125ab7de8d20c129a905a5159972ad9fd1
Author: Ricardo SIGNES <rjbs@cpan.org>
Date: Mon Oct 22 05:01:09 2007 -0400
hostname.t busted
Message-ID: <20071022130109.GA16748@knight>
p4raw-id: //depot/perl@32180
Also fixed in CPAN's libnet since 1.22_02.
We want all programs and libraries produced by perl.spec and other
Perl packages to respect distribution's CFLAGS and LDFLAGS.
This change ensures it. Especially for /usr/bin/perl as well as
non-installed miniperl. The only drawback is /usr/bin/perl gets the
flags twice.
We could poke upstream to fix ExtUtils::MakeMaker and
ExtUtils::CBuilder to respect ldflags what does not happen now. They
use lddlflags only. But we cannot patch them not to diverge from the
world.
Also we disable optimize because optimize is not used everywhere.
This change makes other Perl packages' Makefile.PL's OPTIMIZE argument
redundant. Please note the Build.PL's optimize argument is completly
ignored by Build.PL.