[Bug 784053] New: perl-Sub-WrapPackages provides perl(lib) erroneously
bugzilla at redhat.com
bugzilla at redhat.com
Mon Jan 23 16:53:14 UTC 2012
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl-Sub-WrapPackages provides perl(lib) erroneously
https://bugzilla.redhat.com/show_bug.cgi?id=784053
Summary: perl-Sub-WrapPackages provides perl(lib) erroneously
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-Sub-WrapPackages
AssignedTo: emmanuel.seyman at club-internet.fr
ReportedBy: ppisar at redhat.com
QAContact: extras-qa at fedoraproject.org
CC: emmanuel.seyman at club-internet.fr,
fedora-perl-devel-list at redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
# repoquery --qf '%{SOURCERPM}/%{NEVRA}' --whatprovides 'perl(lib)'
perl-5.14.2-210.fc17.src.rpm/perl-4:5.14.2-210.fc17.x86_64
perl-Sub-WrapPackages-2.0-7.fc17.src.rpm/perl-Sub-WrapPackages-0:2.0-7.fc17.noarch
Why does perl-Sub-WrapPackages provide `perl(lib)'? It redefines package lib in
the middle of lib/Sub/WrapPackages.pm. Sub::WrapPackags POD says:
> Deferred wrapping of subs in packages that aren't yet loaded works
> via a subroutine inserted in @INC. This means that if you mess
> around with @INC, eg by inserting a directoy at the beginning of
> the path, the magic might not get a chance to run. If you "use
> lib" to mess with @INC though, it should work, as I've over-ridden
> lib's import() method. That said, code this funky has no right to
> work. Use with caution!
Please filter `perl(lib)' from set of Provides. I guess other Fedoras than F17
are affected too.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the perl-devel
mailing list