Philippe M. Chiasson wrote:
The main reason this is hapenning is that it's not currently possible to update
CORE packages in ActivePerl, so any module that depends on a CORE package can
be suffering from this. This problem will persist until it becomes possible to
update core packages in ActivePerl.

It's certainly not an ideal situation, but unless somebody can point out an
easier solution, this is where we are at.

I had one of those shower epiphanies this morning. While it's only a concept at this point, I thought I would put it to the group for more experienced minds to consider.

As I understand from comments in http://use.perl.org/comments.pl?sid=30312 the big problem with upgrading core modules for Windows (ActiveState, VanillaPerl, etc.) is that Windows won't delete open files. Thus any core files (particularly *.dll files) in use by PPM/cpan.pm can't be replaced.

So why not bundle a snapshot of all the module dependencies for PPM/cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm?

That way, other than the core perl executable, the upgrade tools wouldn't be using any core modules directly -- only the ones bundled snapshot. If I understand correctly, that should allow core modules to be upgraded.

There's still a bit of a bootstrap problem for upgrading PPM/cpan.pm themselves or any of their dependencies. However, even that might be avoided if the snapshot (including updates to PPM/cpan.pm) were updated/created on the fly by a batch file prior to executing PPM/cpan.pm.

I'm sure moving to this approach would mean changes at various points in the toolchain -- particularly in how the PPM and cpan batch files operate -- but it would avoid more complicated approaches requiring changes in the Windows registry in order to finish upgrades during a reboot.

Thoughts and feedback welcome.

Regards,
David Golden

Reply via email to