I would do it one of the following ways:

• Set up a network drive with just the desired modules (this will take some work)
• Take a snapshot of your desired directory (use autobundle to capture tbe current state)
• Put your entire perl environment on a network drive - you will have to install the modules from each platform (32-bit, 64-bit, Linux, Solaris etc).

Each option will take some work to create your desired environment, but if you then change the configuration modules, you will have a static environment to work with.

Unfortunately, there is no clean way to do this without a significant amount of work, since some of the modules return 0 or 'undef' for the version numbers. Your best bet is to:

1. Capture the current module library via rsync or CPAN::Mini.
2. Upgrade a development machine using the captured library.
3. Test the heck out of it in your known environment.
4. Freeze the configuration and configure your production machines.

You can then configure production to update to the current versions of your perl scripts immediately after upgrading the local images of the perl libraries.

One caveat in storing the perl libraries and in-house scripts locally is that, if there is an issue, it takes local intervention to fix a problem or update to a new version. Networked installations (depending on network size) can often be much cleaner.

HTH

Update:
I missed one point here:

This is not surprising I suppose, since cpan is parsing and using /root/.cpan/Metadata which likely stores info from when I was working with a public cpan repository, but I only want it to look at what is in the local repository I am setting up.

Also use "reload index" in CPAN or "x --update-source" in CPANPLUS to recreate the indices with your private repository information.