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@xxxxxxxxxxxxxxxx ReportedBy: ppisar@xxxxxxxxxx QAContact: extras-qa@xxxxxxxxxxxxxxxxx CC: emmanuel.seyman@xxxxxxxxxxxxxxxx, fedora-perl-devel-list@xxxxxxxxxx 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
