Re^2: help managing modules using CPAN.pm

1. How do I uninstall modules?

uninstalling modules should give you some hints. But I personally never uninstall modules (unless there is a big problem), and I install quite a few to look at and test out. They're generally small (disk space is cheap) and generally don't conflict with each other. On the very rare occasion I do uninstall a module - I do it by hand (IIRC I've only done that once over 8+ years).

When you say "by-hand"... the times I've checked, I haven't seen a "make uninstall" target for the modules I've installed. Is that common (to not have an uninstall target)? If so, how do you uninstall?

I generally install by CPAN but about 1/4 of the time tests will fail. I then revert to installing by hand to see what tests fail and if I'm concerned about them.

Ahhh... I see. Thank you.

But, when you say you "install by-hand", does that mean you go to where CPAN.pm downloaded the source files (umm... maybe somewhere in /root/.cpan?) and run "perl Makefile.PL..."? Or do you download a fresh archive?

There is the upgrade command from CPAN. But be careful. You need to watch modules you heavily depend on (like DBI and your DBD's, and DBIx::Class) for interface changes. I wouldn't use any kind of automation for this /me is paranoid

So, how exactly do you "upgrade by-hand" if you've already got the previous version installed? If I were going from using a 1.x to a 2.x, I'd want to make sure all the 1.x files were completely removed first, right?

Comment on Re^2: help managing modules using CPAN.pm

Replies are listed 'Best First'.

Re^3: help managing modules using CPAN.pm
by grep (Monsignor) on Nov 13, 2006 at 20:19 UTC

Uninstalling by hand means going to you lib/perl5/ and deleting the files. This can be dangerous, but if you take care it's easy and quick. But my main point was don't worry too much about uninstalling modules.

perl Makefile.PL

make

make test

su -c 'make install'

Unless specified by the POD documentation you shouldn't have to worry about removing old modules. They should be overwritten. After install hundreds of modules I can't think of any real upgrade weirdness other than once with a big update to Class::DBI. But since I generally do upgrades one-at-a-time, it was easy to find out where to update my code.

grep

XP matters not. Look at me. Judge me by my XP, do you?

[reply]
[d/l]
[select]

Re^4: help managing modules using CPAN.pm

by j3 (Friar) on Nov 13, 2006 at 22:42 UTC

Thanks grep!

[reply]

Re^3: help managing modules using CPAN.pm
by bingos (Vicar) on Nov 14, 2006 at 05:31 UTC

I have always used the method listed in the CPAN FAQ to remove unwanted modules.

It is also possible to remove individual module files using:

rm `perldoc -l Module::Name`
[download]

Using the look command in the CPAN shell will drop you into that particular module's build directory so that you can run the installation commands 'manually'

Using something like the following should upgrade modules removing conflicting module versions. Both CPAN and CPANPLUS can be configured to add the UNINST option when running make:

perl Makefile.PL
make
make test
make install UNINST=1
[download]

[reply]
[d/l]
[select]

Re^4: help managing modules using CPAN.pm

by j3 (Friar) on Nov 14, 2006 at 07:28 UTC

That was a very pithy post bingos. Thank you for those details. :)

[reply]

Re^3: help managing modules using CPAN.pm
by bart (Canon) on Nov 14, 2006 at 12:47 UTC

But to uninstall, just delete each file listed in the file. Except... if the installation replaced an older version of the same module, and I mean physically replace: placing the files on top of the old ones, well this will obviously not restore the old files.

I think you're then better off installing the old module over the new one, or at least have the archive ready in case it's an essential module to even be able to run CPAN.pm, so you can install them just using make and perl. Or install at a new location, delete the old files, and move the new files in place. Something like that.

Yes a process like this should be automated, IMO.

update I looked: the text file with the file listing is called ".packlist", and it resides somewhere under the "auto" root, in the module root where it's installed. For example, if the module is "Test::Pod" which is installed in "site/lib", then this file ought to be at "site/lib/auto/Test/Pod/.packlist".

[reply]
[d/l]
[select]


Keep It Simple, Stupid
	PerlMonks