maxim wexler schreef: >>That's one way. Perl-cleaner can also be found in >>/usr/portage/dev-lang/perl/files. > > > #perl-cleaner allmodules > > did the deed. Thanks Holly. BTW, where are these > modules and how do they differ from the ones residing > under /lib/modules? >
The modules in /lib/modules belong to the kernel for those 'drivers' specified to be compiled as modules (rather than statically compiled into the kernel itself), as well as those outside kernel modules that may be compiled later-- like the ATI video drivers used on my system, which are not compiled as part of the kernel compilation process (being a separate, proprietary download), but are compiled *against* the kernel afterwards, then inserted into /lib/modules/kernel-version (because they are ultimately kernel drivers, responsible for detecting and supporting a piece of system hardware). The Perl modules are found in /usr/lib/perl5/perl.versi.on, and have nothing to do with the kernel, but similarly expand the capabilities of Perl and Perl-based operations in the same way that kernel modules expand (or restrict) the capabilities of the kernel to detect specific hardware. But that's what a module is all about, anyway. The 'problem' in this case is that (imo based on my experience): 1) certain "unrelated" programs that depend on/use Perl operations (as opposed to Python or Java or some other language) for their functioning further require that Perl have certain modules installed for the program's Perl-dependent functioning to work (you can see why Firefox would need Perl to be able to read and parse XML if Firefox was going to use Perl in some respect, given that XML is used frequently in web-pages of various sorts), and 2) certain Perl modules (notably the XML Parser, in my experience) tend strongly towards "breakage" when Perl is upgraded (meaning not that any given module itself actually 'breaks', but that said module is not successfully transferred/registered to associate itself with the new version as the majority of other previously-installed modules are). I found this to occur most often during 'moderate' upgrades of Perl (from 5.x.whatever to 5.y.whatever), rather than for 'minor' upgrades (5.8.x to 5.8.y), but it can occur at any time. Therefore-- since I refuse at this time to become expert in the workings of the mind of Perl-- I've just trained myself to run perl-cleaner after any upgrade to Perl (which doesn't happen that often, really), as advised by the emerge process itself: > eerror "You have had multiple versions of perl. It is recommended" > eerror "that you run perl-cleaner now. perl-cleaner will" > eerror "assist with this transition. This script is capable" > eerror "of cleaning out old .ph files, rebuilding modules for " > eerror "your new version of perl, as well as re-emerging" > eerror "applications that compiled against your old libperl.so" It's a pain (because perl-cleaner does take a while, but it's still faster than the previous 'perl-rebuilder' or whatever it was called, and also seems more reliable and 'professional' than that script), but hey, that's life with Linux (some things are a pain), and $DEITY bless Gentoo for having a tool to handle this with the minimum disturbance possible (the agonizing wait is unavoidable, but everything else is automated... and that would be Gentoo, in a nutshell :-D). HTH, Holly -- gentoo-user@gentoo.org mailing list
