There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
1. It's in very rare events that CPAN modules need to be uninstalled, in my experience manually deleting the .pm/.xs, etc files in @INC works best. Although, you see many people will disagree and have gone so far as to write modules to assist in this operation.
2. Configuring CPAN is a necessary burden, also I don't think closing your eyes and picking a random mirror has a significant impact, I just choose the well-known (or seemingly well known) mirrors. 3. Some CPAN packages in the debian package pool are outdated, some by months/in excess of 2 or more revisions. I was amazed to find out just how many seem are actually outdated when i used the CPAN shell to upgrade. Also, debian-perl maintainers might be inclined to choose a different package to satisfy a dependancy when infact you might already have the necessary header files available locally (from other source or debian packages). In my opinion, CPAN/CPANPLUS seems to be the way to go - configuring from source and all that, it's definitely longer and sometimes requires manual interaction but since CPAN.pm is a perl module, it means installing perl modules from within perl script is possible. 5. perl -MCPAN -e upgrade 6. CPAN isn't as bleeding edge as CPANPLUS but it's definitely still chugging along. Michael Schwern, author of Module::MakeMaker seems to suggest using CPANPLUS vehemently, quite plausibly because CPANPLUS has better support for Module::Build and also because it's just pretty much better structured than CPAN (which could do with a complete rewrite). I should think CPAN and CPANPLUS will continue to live on contending, just as GNOME/KDE, Firefox/IE, etc. 7. It's quite hard to botch up on installing perl modules, even if you should, leaving them be isn't going to impact you in any significant way unless they were incompletely installed. In any case, using a 'forced install' of CPAN::install() seems to effectively reinstall those modules (with the added disadvantage of test errors being turned into warnings).
In reply to Re: help managing modules using CPAN.pm
by Anonymous Monk
|
|