Bug 3731 - Missing perl-base version number dependency
Summary: Missing perl-base version number dependency
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Olivier Blin
QA Contact:
Depends on:
Reported: 2011-12-13 21:54 CET by Dan Fandrich
Modified: 2011-12-15 00:02 CET (History)
2 users (show)

See Also:
Source RPM: drakxtools-13.72.1-1.mga2.src.rpm
Status comment:


Description Dan Fandrich 2011-12-13 21:54:15 CET
Installing drakxtools-backend-13.72.1-1.mga2 from Cauldron on a Mageia 1 installation succeeds, but doesn't run. When subsequently installing a new kernel, this error message is displayed:

/usr/bin/perl: symbol lookup error: /usr/lib/libDrakX/auto/c/stuff/stuff.so: undefined symbol: Perl_xs_apiversion_bootcheck

This is because the version of perl installed on Mageia 1 does not contain the Perl_xs_apiversion_bootcheck (and Perl_xs_version_bootcheck) exports.

The solution is to install a new perl-base package. The perl-base dependency on drakxtools-backend-13.72.1-1.mga2 should be enhanced to specify a version of perl that includes that export (presumbably, perl-base>=5.14.2 would suffice).

It looks like the new Perl_xs_apiversion_bootcheck dependency is due to a change in perl from using a macro to a function call in order to perform some version checking. That means that presumably other perl extension packages will also have the same problem as drakxtools-backend.
Comment 1 Manuel Hiebel 2011-12-13 22:31:19 CET
Installing drakxtools-backend-13.72.1-1.mga2 from Cauldron on a Mageia 1
installation succeeds, but doesn't run. 

Why on a Mageia 1, we don't support backport...
Comment 2 Dan Fandrich 2011-12-13 22:42:05 CET
I'm just trying to upgrade the kernel since the one on Mageia 1 crashes on me all the time. If the dependencies are right, there should be nothing stopping that from working.
Comment 3 Manuel Hiebel 2011-12-13 23:04:07 CET
Yes but a least you need to rebuild the srpms and not only take randomly the rpms.

So it's more a wontfix resolution.
Comment 4 Manuel Hiebel 2011-12-14 02:26:32 CET
Iirc it's need also a rebuild because it's not the same version of perl, but I don't really see the point to take drak* from cauldron for mga 1

added the maintainer, maybe I am wrong

Assignee: bugsquad => thierry.vignaud

Comment 5 D Morgan 2011-12-14 02:47:39 CET
and in addition perl of cauldron is not binary compatible with previous one. This  have been warned on dev ML and this explain your pb.

In +, if you install on your mageia 1 a perl rpm from cauldron this is like russian roulette, because it may and often happen that the perl modules are not in the @INC because you can for ex ( this is just an exemple ) have perl 5.12.2 and if cauldron have perl 5.12.3, new modules built on cauldron will install in /usr/lib/perl5/5.12.3/ which *won't* be in the @INC of mageia 1 so it won't work.

If you did this for a kernel bug, the best is to open a bugreport against mageia 1 ( if not already done )

i hope i provided some infos ( and that i didn't told too many errors )

CC: (none) => dmorganec

Comment 6 Thierry Vignaud 2011-12-14 09:49:11 CET
Clearly an invalid usage

Resolution: (none) => INVALID

Comment 7 Olivier Blin 2011-12-14 22:50:51 CET
Even if the use case is invalid, the bug report is legit.
We should require the proper perl version if a perl package contains some XS modules, to ensure consistency when updating perl packages.
This is a normally a job for find-requires, which adds a perlapi requirement for packages containing perl XS modules.

It might be broken for drakxtools because it does not install the XS module to a standard perl location. We should either add the perlapi requirement manually in the package, or move the XS files to a standard location.

CC: (none) => mageia
Resolution: INVALID => (none)

Thierry Vignaud 2011-12-14 22:55:49 CET

Assignee: thierry.vignaud => mageia

Comment 8 Olivier Blin 2011-12-15 00:02:32 CET
Fixed in 13.72.1-2.mga2

Resolution: (none) => FIXED

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