The only problem with this is that it only deals with CPAN.pm itself.
The problem with locked files is wider than this.
Imagine for example that you have Windows mod_perl or some other
long-running program holding a lock on the modules.
I had a similar idea last week, where maybe we could have CPAN.pm's
module loader copy the files into a temp directory and load those ones.
But unfortunately I think that isn't a good long term solution. Assuming
we can reach the point where Win32 Perl (with CPAN.pm) is much much more
common, we will end up with services and other things, and dealing just
with CPAN.pm's own file locks aren't quite enough.
The new ExtUtils::Install does really do the right thing though, and
Win32 Perl is much more upgradable that any others, most 5.005
installations are in places like Irix these days.
So I'd like to see where we get to once the new ExtUtils::Install is out
and we can install properly, and then if there are still problems after
that, we take the next step.
Adam K
David Golden wrote:
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
