On Sun, Sep 17, 2006 at 01:46:23PM -0700, Ian Burrell wrote: > > > > Removing support for perl 5.8.3 and perl 5.8.4 reduces the number > > of directories in the perl search path (@INC), which improves the > > perl modules loading time. > > > > This has already been done in past for FC-4 where support for > > perl 5.8.0/5.8.1/5.8.2 has dropped. [...] > > perl specfile patch: > > -------------------- > > --- perl.spec.588_8 2006-07-14 22:22:06.000000000 +0100 > > +++ perl.spec 2006-09-17 16:10:58.000000000 +0100 > > @@ -26,9 +26,7 @@ > > Provides: perl(:WITHOUT_THREADS) > > %endif > > > > -%define perlmodcompat 5.8.7 5.8.6 5.8.5 5.8.4 5.8.3 > > -Provides: perl(:MODULE_COMPAT_5.8.3) > > -Provides: perl(:MODULE_COMPAT_5.8.4) > > +%define perlmodcompat 5.8.7 5.8.6 5.8.5 > > Provides: perl(:MODULE_COMPAT_5.8.5) > > Provides: perl(:MODULE_COMPAT_5.8.6) > > Provides: perl(:MODULE_COMPAT_5.8.7) > > -------------------- > > > > Note: > > The FC-4 change was reported in the Release Notes. > > I thought the FC-4 change was done because 5.8.6 was not binary > compatible with modules built for 5.8.2 and earlier. Perl changed > binary module compatibility at 5.8.3. All versions since then have > maintained binary module compatibility. The FC-3 perl 5.8.5 had a bug > in that it included the MODULE_COMPAT_5.8.2 and earlier and could have > loaded incompatible modules. > > How big is the performance boost? Checking use DBI; using strace perl -MDBI -e 1 2>&1 | egrep '5.8.[34]' | wc -l shows 240 stat64's, all coming from searches in site_perl and vendor_perl directories. For -MCGI it's 164. However: what happens if the user was upgrading from older perls and still has some (presumably nonstandard) modules in these paths? Will the %post somehow move them to newer directories? -- Jan Pazdziora RHN Sustaining Engineering, Red Hat
