On 3/16/06, David Golden <[EMAIL PROTECTED]> 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.
Im not sure if you realized, but you can install YVES/ex-ExtUtils-Install-1.3701.tar.gz and assuming you have Win32API::File installed this stuff will be handled properly. This package is a proposed split off of the installation code in the ExtUtils::MakeMaker bundle. We are waiting on Schwern to respond And while your suggestion probably would work I don't it would resolve all the issues. For instance perhaps you want to upgrade files that are locked because of other reasons beside the installer having them open. For instance you might want to upgrade the .dlls used by a long running perl. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
