(This might have been adressed here already, and if so please ignore me :-X)
This blog post contains the details: http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
I incorporated the patches from a core perl dev <http://use.perl.org/~nicholas/journal/37274> which through some simple testing seems to fix the slowdowns while allowing one to retain all the Red Hat perl patches. This is not the fedora patch which still has the potential for slowdowns.
As far as @INC is concerned, we patch our RHEL4 perl to use site_perl before vendor_perl (RHEL5 already does it this way). I've also started building my perl modules with /usr/local prefix for mandir, datadir, etc to avoid any conflicting files in the base perl package.
Dag Wieers wrote:
On Wed, 17 Sep 2008, Dave Cross wrote:Dag Wieers wrote:That is why I think we need to somehow make Red Hat understand that they should not add CPAN distributions to the perl package.It's not Red Hat that does this. The standard Perl distribution contains modules that are also distributed independently from CPAN. They are known as "dual-life" modules.Right. But the fact that they are part of the perl RPM and not packaged as seperate RPMs makes it hard to replace them. Nothing forces Red Hat to ship them with the perl RPM.In the past I thought it was because Red Hat did not want those modules to be replaced (given they have to support the system) and the default module path ctually confirmed that.But since RHEL5 they allow to replace modules from site_perl because they changed the order, so there goes the bit of reverse psychology :) So I would have expected them to package them seperately so that at least it is more obvious from the package database that a certain RPM was in fact replaced.
perl58-slow-overloading.patch.gz
Description: application/gzip
_______________________________________________ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
