Upgrading Strawberry Perl While Preserving Non-Core Modules

roho has asked for the wisdom of the Perl Monks concerning the following question:

I am planning to upgrade Strawberry Perl on Windows 10 (from 5.24.1 to 5.32.1.1), while preserving existing non-core modules. I found the following notes from a few years ago and am wondering if they are still correct and valid, because I don't want to mess this up.

1. Create autobundle: cpan -a <strong>  (this step ran successfully)
2. Install new version of Strawberry Perl.
3. Reload/rebuild modules: perl -MCPAN -e "install Bundle::Snapshot_20
+22_04_29_00"
[download]

Questions:

Since "cpan -a" generates its module in: "C:\strawberry\cpan\Bundle\Snapshot_2022_04_29_00.pm", this implies installing the new version of Perl in the existing "C:\strawberry\..." directory. Is this a problem?
The only other option I see is to rename "C:\strawberry" to "C:\strawberryOLD", do a clean install of the new version, copy the generated autobundle module from the old renamed directory to the new "C:\strawberry", then run step 3 above. Is this a problem?

Note: The reason I'm being so cautious is because I have quite a few non-core modules (over 6,500) to preserve between versions.

All comments and suggestions are welcome and appreciated.

"It's not how hard you work, it's how much you get done."

Comment on Upgrading Strawberry Perl While Preserving Non-Core Modules Download Code

Replies are listed 'Best First'.
Re: Upgrading Strawberry Perl While Preserving Non-Core Modules by Fletch (Bishop) on Apr 29, 2022 at 21:37 UTC
5.24 and 5.32 aren't going to be binary compatible so you're going to need to let everything XS reinstall in the new perl anyhow. That being said the autobundle file (which seems to be coming up a lot today) is just a specially formatted module file naming the modules to be installed. If you installed your new 5.34 under (say) `C:\strawberry534` you should be able to copy the 5.24 bundile file into `cpan\Bundle` in the new location and the 5.34 cpan should (theoretically) find it there and install into the new directory. (Disclaimer: not a windows person and just guessing about multiple installs with different prefixes. Hands waving wildly. Contents may have settled during shipping.) The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re: Upgrading Strawberry Perl While Preserving Non-Core Modules by syphilis (Archbishop) on Apr 30, 2022 at 02:44 UTC
... "cpan -a" generates its module in: "C:\strawberry\cpan\Bundle\Snapshot_2022_04_29_00.pm" ... I have many (lost count) perls of different versions and configurations on my Windows box - some were provided by the Strawberry Perl project, others not. The one thing I do like is that they all use the same cpan directory - namely \Users\me\.cpan. I'm not sure how this is achieved, but every time I install a new windows perl (whether it's from Strawberry or not), the cpan utility just automatically uses C:\Users\me\.cpan as its cpan directory. Perhaps this is partly reliant on the HOMEDRIVE and HOMEPATH environment variables which, for me, specify (respectively) `C:` and `\Users\me`. The only snag I've ever encountered with this arrangement is that .cpan/CPAN/MyConfig.pm likes to name the actual flavour of make - but that flavour could be any of `gmake`, `dmake` or `nmake`. I've therefore altered my \Users\me\.cpan\CPAN\MyConfig.pm to begin with: `use Config; $make = $Config{make} =~ /dmake/ ? q[C:\\_32\\dmake\\dmake.EXE] : $Config{make} =~ /nmake/i ? $Config +{make} : q[C:\\_ +32\\make\\bin\\make.EXE];` [download] (You could just specify `$make = $Config{make}` if you're sure that the requisite flavour of make is going to be in your path.) Additionally, further down in MyConfig.pm, the `'make'` setting needs to be altered to `'make' => $make,` Note that on 64-bit Windows, it doesn't matter whether the make utility (of whatever flavour) is 32-bit or 64-bit. Out of curiosity, I ran `cpan -a` in quick succession from 2 different perls. The 1st created \Users\me\.cpan\Bundle\Snapshot_2022_04_30_00.pm . The 2nd created \Users\me\.cpan\Bundle\Snapshot_2022_04_30_01.pm . I regard this unifying of the CPAN directories as one of the "smartest things I ever did". And, as with most of the other "smartest things I ever did", I'm not exactly sure just how I did it ;-) Cheers, Rob	[reply] [d/l] [select]
Re: Upgrading Strawberry Perl While Preserving Non-Core Modules by stevieb (Canon) on Apr 30, 2022 at 17:40 UTC
If you use berrybrew, you need not do anything at all with your existing install. Install berrybrew via its installer. During the install, you can select a version of perl to install with it Switch to the new instance: `berrybrew switch 5.32.1` (or via the UI) Install the bundle You can also register your existing Perl installation with berrybrew if you desire: `berrybrew virtual some_name`, then follow the prompts to enter path information.	[reply] [d/l] [select]
Re: Upgrading Strawberry Perl While Preserving Non-Core Modules by LanX (Saint) on Apr 29, 2022 at 20:45 UTC
on a meta level... > because I don't want to mess this up. I don't think you have to worry much about this. My experience with Perl installation trees on Win is that they are easy to copy and even transfer to other machines. So I'd say make a backup, test it's reliability and zip it. Than simply try out your upgrade scenarios and test again. In case of problems just restore the backup. > All comments and suggestions are welcome and appreciated. HTH! :) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery} update > I have quite a few non-core modules (over 6,500) to preserve between versions. which makes a valid backup mechanism even more urgent.	[reply]
Re: Upgrading Strawberry Perl While Preserving Non-Core Modules by roho (Bishop) on May 01, 2022 at 05:20 UTC
Thank you all for your comments and suggestions. "It's not how hard you work, it's how much you get done."	[reply]

update