Jan Pazdziora <jpazdziora@xxxxxxxxxx> writes: [...] >> 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? I'm not really sure how that would work - has this been done in the past? It would be tricky in the first place to tell which ones are 'nonstandard' - I guess 'not owned by an rpm, and wouldn't be copied over a file owned by an rpm' would be a good heuristic to start with. That seems a little bit more magic than is healthy for a %post script. OTOH, I'd rather not break everyone's perl modules. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching
