How do I find and delete duplicate Perl modules from the library?

I've been using Module::Build to manage my module installation and I've found that I have duplicate versions of a given module in different parts of the library:

./site_perl/5.14.2/i686-linux/site_perl/Support/Dump.pm
./site_perl/5.14.2/Support/Dump.pm

This is a concern to me, because I can't be sure that they will stay 开发者_如何转开发in sync.

Is there a way to find and remove duplicate files of this sort? Or are these here because of something that I did and can I control that?

That's probably because you added/removed XS code from your module. If you added XS code, the first one is the current one (good), if you removed all XS code, the second one is the current one (not good). This is unlikely to be a long-term problem, so a long-term solution may be unnecessary.

If you run perl -V, you'll notice the order of every path in your @INC. Perl will likely have your i686-linux/site_perl directory before the normal one, so your XS version will get loaded, and the other one will be ignored. It doesn't matter if they're in sync or not, only one will get loaded. Thus, the important thing is that if you remove all the XS code so it becomes a pure-perl module, you'll have to delete the XS version from your tree. This is rare - once you start doing XS, usually it's not removed. Even dual-life modules (List::MoreUtils) keep their XS code and merely have a way to determine if it got installed or not, and have a way to disable the XS code for testing purposes. But they don't actually get rid of the XS code.

Most likely, you added XS code so it was no longer pure-perl, and everything will be fine.

Why? Is it causing a problem? Identifying all the files from a distribution could be tricky, so trying to remove an installed distribution is more likely to cause a problem than leaving things be.

You said you're worried about the installations getting out of sync, but that makes no sense. Why do you care about the state of an installation you're not using?

You will most likely always have some duplicate looking Modules, because the modules are installed in one (or more) of the paths defined in @INC list. If you inspect the modules versions with cpan -l, you will probably discover that they have different versions. Please see this answer for many more details.

However one can always argue to wonder why Perl never supplied a more sane (and people friendly) way to organize and inspect the modules that has been installed.