| 1 |
maxim wexler schreef: |
| 2 |
>>That's one way. Perl-cleaner can also be found in |
| 3 |
>>/usr/portage/dev-lang/perl/files. |
| 4 |
> |
| 5 |
> |
| 6 |
> #perl-cleaner allmodules |
| 7 |
> |
| 8 |
> did the deed. Thanks Holly. BTW, where are these |
| 9 |
> modules and how do they differ from the ones residing |
| 10 |
> under /lib/modules? |
| 11 |
> |
| 12 |
|
| 13 |
The modules in /lib/modules belong to the kernel for those 'drivers' |
| 14 |
specified to be compiled as modules (rather than statically compiled |
| 15 |
into the kernel itself), as well as those outside kernel modules that |
| 16 |
may be compiled later-- like the ATI video drivers used on my system, |
| 17 |
which are not compiled as part of the kernel compilation process (being |
| 18 |
a separate, proprietary download), but are compiled *against* the kernel |
| 19 |
afterwards, then inserted into /lib/modules/kernel-version (because they |
| 20 |
are ultimately kernel drivers, responsible for detecting and supporting |
| 21 |
a piece of system hardware). |
| 22 |
|
| 23 |
The Perl modules are found in /usr/lib/perl5/perl.versi.on, and have |
| 24 |
nothing to do with the kernel, but similarly expand the capabilities of |
| 25 |
Perl and Perl-based operations in the same way that kernel modules |
| 26 |
expand (or restrict) the capabilities of the kernel to detect specific |
| 27 |
hardware. |
| 28 |
|
| 29 |
But that's what a module is all about, anyway. The 'problem' in this |
| 30 |
case is that (imo based on my experience): |
| 31 |
|
| 32 |
1) certain "unrelated" programs that depend on/use Perl operations (as |
| 33 |
opposed to Python or Java or some other language) for their functioning |
| 34 |
further require that Perl have certain modules installed for the |
| 35 |
program's Perl-dependent functioning to work (you can see why Firefox |
| 36 |
would need Perl to be able to read and parse XML if Firefox was going to |
| 37 |
use Perl in some respect, given that XML is used frequently in web-pages |
| 38 |
of various sorts), and |
| 39 |
|
| 40 |
2) certain Perl modules (notably the XML Parser, in my experience) tend |
| 41 |
strongly towards "breakage" when Perl is upgraded (meaning not that any |
| 42 |
given module itself actually 'breaks', but that said module is not |
| 43 |
successfully transferred/registered to associate itself with the new |
| 44 |
version as the majority of other previously-installed modules are). |
| 45 |
|
| 46 |
I found this to occur most often during 'moderate' upgrades of Perl |
| 47 |
(from 5.x.whatever to 5.y.whatever), rather than for 'minor' upgrades |
| 48 |
(5.8.x to 5.8.y), but it can occur at any time. Therefore-- since I |
| 49 |
refuse at this time to become expert in the workings of the mind of |
| 50 |
Perl-- I've just trained myself to run perl-cleaner after any upgrade to |
| 51 |
Perl (which doesn't happen that often, really), as advised by the emerge |
| 52 |
process itself: |
| 53 |
|
| 54 |
> eerror "You have had multiple versions of perl. It is recommended" |
| 55 |
> eerror "that you run perl-cleaner now. perl-cleaner will" |
| 56 |
> eerror "assist with this transition. This script is capable" |
| 57 |
> eerror "of cleaning out old .ph files, rebuilding modules for " |
| 58 |
> eerror "your new version of perl, as well as re-emerging" |
| 59 |
> eerror "applications that compiled against your old libperl.so" |
| 60 |
|
| 61 |
|
| 62 |
It's a pain (because perl-cleaner does take a while, but it's still |
| 63 |
faster than the previous 'perl-rebuilder' or whatever it was called, and |
| 64 |
also seems more reliable and 'professional' than that script), but hey, |
| 65 |
that's life with Linux (some things are a pain), and $DEITY bless Gentoo |
| 66 |
for having a tool to handle this with the minimum disturbance possible |
| 67 |
(the agonizing wait is unavoidable, but everything else is automated... |
| 68 |
and that would be Gentoo, in a nutshell :-D). |
| 69 |
|
| 70 |
HTH, |
| 71 |
Holly |
| 72 |
-- |
| 73 |
gentoo-user@g.o mailing list |
Archives