Description of problem: perl(Inline) is provided and required by both perl-PDL and also perl-Inline. Any way they could be separated or removed? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Recommendations?
--- perl-PDL.spec.241_11 2005-05-12 05:28:34.000000000 +0100 +++ perl-PDL.spec 2005-05-25 21:25:12.000000000 +0100 @@ -34,7 +34,15 @@ %patch0 -p1 -b .settings %patch1 -p1 -b .long -# Explicitly filter perl(Tk) +# Provides: explicitly filter perl(Inline) +cat <<__EOF__ > %{name}-findperlprovides +#!/bin/sh +/usr/lib/rpm/perl.prov $* | grep -v 'perl(Inline)' +__EOF__ +%define __perl_provides %{_builddir}/PDL-%{version}/%{name}-findperlprovides +chmod +x %{__perl_provides} + +# Requires: explicitly filter perl(Tk) cat <<__EOF__ > %{name}-findperlrequires #!/bin/sh /usr/lib/rpm/perl.req $* | grep -v 'perl(Tk)'
Note that if you just filter out the perl(Inline) Provides here, this package will after the change depend on the perl-Inline package which it did not do earlier, because the autogenerated perl(Inline) dependency will still be there. It should be verified if this is the right thing. Another cosmetic note: if one hardcodes /usr/lib/rpm/perl.(prov|req) and thus theoretically overrides the system rpmbuild configuration, the filter scripts could be separated into files of their own instead of embedding them in the specfile. On the other hand, since they're already embedded, /usr/lib/rpm/perl.(prov|req) could be replaced with %{__perl_provides} and %{__perl_requires} in the emitted scriptlets to make them automatically play nice with possible future rpm config changes.
Oh, and "$*" should be backslashified in the embedded scripts like "\$*", otherwise it won't end up in the output. Not that it would matter currently...
PDL: provides/requires 1) provide: perl(Inline) Caused by the following hack in the file Inline/MakePdlppInstallable.pm ---------- package Inline::MakePdlppInstallable; # just a dummy package package Inline; #==================================================================== # override the original Inline::install method # to allow Inline::Pdlpp code to be installed ... ---------- The above comment goes on and explains why the hack is there. 2) The requirement perl(Inline) appears to be valid unless there is no interest in using Inline::Pdlpp. a) The Inline module is required by the module Inline::Pdlpp (file Inline/Pdlpp.pm) ---------- package Inline::Pdlpp; use strict; require Inline; ... ---------- b) From the Inline::Pdlpp documentation ---------- ... You never actually use Inline::Pdlpp directly. It is just a support module for using Inline.pm with PDL::PP. So the usage is always: use Inline Pdlpp => ...; ... ---------- Source: http://search.cpan.org/dist/PDL/Basic/Gen/Inline/Pdlpp.pm#Usage
Created attachment 114859 [details] perl-PDL specfile patch: includes Ville's suggestions
Rel-eng said this isn't a showstopper, so this goes into FC5. Does this actually cause trouble beyond "two packages are pulled in when you Require Inline"? I am guessing no, so this doesn't need to go into FC4 Updates either.
Also for FC5: * Update PDL to version 2.4.2 (2005-01) http://search.cpan.org/dist/PDL/
ia64 build failure of this plus perl-PDL-2.4.2. All other archs succeeded build and tests. Please advise. t/dumper....................Fatal error: argument is probably not a piddle, or magic no overwritten. You're in trouble, guv: 195584 9360880 8181832 (in cleanup) Fatal error: argument is probably not a piddle, or magic no overwritten. You're in trouble, guv: 195488 9331696 9416000 (in cleanup) Fatal error: argument is probably not a piddle, or magic no overwritten. You're in trouble, guv: 195584 9360880 8181832 (in cleanup) Fatal error: argument is probably not a piddle, or magic no overwritten. You're in trouble, guv: 195632 9330992 9185776 dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 6-16 Failed 11/16 tests, 31.25% okay t/gsl_interp................dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 1-10 Failed 10/10 tests, 0.00% okay Summary: Failed 3/96 test scripts, 96.88% okay. 21/797 subtests failed, 97.37% okay.
Attempted build again today. Only one test failure on ppc: t/primitive.................# Failed test 20 in t/primitive.t at line 120 # t/primitive.t line 120 is: eval '$c = all($b==pdl([[0,1],[2,2]]))'; ok(!$@ && $c); FAILED test 20 Upstream CPAN shows mostly failures on this module version, and seems unwilling or unable to fix this module after a few months of failure. So this leaves us with few options: 1) Disable tests and allow this to go into rawhide, assuming it is only a problem of the tests themselves (?) 2) Downgrade to the previous version and hope that it works. 3) Fix the problem, whatever it is. Opinions?
This is fixed with the current packages in FC-development. Thanks, Florian La Roche
From User-Agent: XML-RPC perl-PDL-2.4.2-2.fc4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
perl-PDL-2.4.2-2.fc4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.