23

The question How do I upgrade strawberry perl without wiping \perl\site\lib\ and \perl\site\bin\? was asked in 2011 and it appears Strawberry did throw out any CPAN installs the user did whenever we upgraded to a newer version. Is this still the case? I found a comment from Adam Kennedy which seems related but I'm not sure whether the change was actually made and what its implications are.

Since Strawberry Perl is said to be "100% Open Source" I tried looking for a development site, a place where we could get more details and look at discussions, but I couldn't find any, the strawberryperl.com site is strangely devoid of any information in this regard. Even its Wikipedia page is (slightly) more informative. (Edit: I found http://code.google.com/p/strawberry-perl/ which could be a neat central portal of links, also http://search.cpan.org/~kmx/Perl-Dist-Strawberry-3.012/script/perldist_strawberry is quite informative.)

Also, in case Strawberry still does this, how can I make a local backup copy of the modules? I don't want to have to use CPAN's autobundle and redownload everything from scratch unnecessarily.

Update for future reference: from the comments I gather that since the content in site/lib and site/bin are currently build-dependent in Strawberry Perl, it's necessary to wipe them out and start afresh when installing a new version. This necessity might go away if Strawberry introduces a separate arch-directory to store architecture dependent stuff.

Community
  • 1
  • 1
Sundar R
  • 13,776
  • 6
  • 49
  • 76
  • 1
    Strawberry Perl uses normal Perl infrastructure – here is the corresponding [CPAN module](https://metacpan.org/module/Perl::Dist::Strawberry) which also links to the bugtracker, and some repository. – amon Sep 04 '13 at 09:43
  • @amon Thanks. I had somehow overlooked the direct Request Tracker link in their support page. I wasn't able to find this problem in either the Active or Resolved bugs there though (may have simply missed it). – Sundar R Sep 04 '13 at 10:08
  • Ok, it looks like Strawberry5.18 requires you to uninstall previous installations before getting installed, and the uninstall process seems to delete the C:\strawberryperl directory entirely, so I guess the question is really about the uninstall process? Was this different back then, did Strawberry actually allow upgrades directly? Or is the other question also talking about the uninstall process? – Sundar R Sep 04 '13 at 10:55
  • If Strawberry is like AS, it doesn't use an arch. The site is therefore build-specific. You will have to reinstall the contents even if it didn't get wiped. – ikegami Sep 04 '13 at 11:34
  • @ikegami What does "doesn't use an arch" mean? – Sundar R Sep 04 '13 at 12:22
  • It's a group of directories. Grep arch in `perl '-V:install.*'` and http://p3rl.org/ExtUtils::MakeMaker – daxim Sep 04 '13 at 12:41
  • (arch)itechture-specific directory, such `lib/MSWin32-x64-multi-thread`, or better yet, `lib/5.18.1/MSWin32-x64-multi-thread`, a directory under the lib directory to hold build-specific installations. In other words, I said that if Strawberry is like ActivePerl, there's no way to determine if an installed module will only work with a specific build (e.g. if it has an XS component) or if it can be used by any `perl` (e.g. most Pure Perl modules), so one has to assume they're all the former. – ikegami Sep 04 '13 at 13:12
  • (Turns out my 5.18.1 ActivePerl install at work uses an archlib, but my 5.16.??? at home doesn't.) – ikegami Sep 04 '13 at 13:12
  • @ikegami Thanks! I'm not sure I understand this correctly, but it looks like the only cases affected by retaining site while not having an arch are XS modules where the underlying hardware has changed beneath them. Is this correct, or does "build-specific" refer to the specific build of Perl environment itself? – Sundar R Sep 04 '13 at 13:25
  • 2
    Has nothing to do with hardware, and all to do with the Perl version, build settings (e.g. threaded or not) and maybe build environment (e.g. location of external libraries?) – ikegami Sep 04 '13 at 14:11
  • 1
    "This necessity might go away if Strawberry introduces a separate arch-directory to store architecture dependent stuff. " Actually, if you get a new version of perl, the arch dependent stuff has to be nuked too, because major perl releases are not ABI compatible with each other. So even if those directories are still there, you'll want to nuke them, and nuking them will break the stuff in the non-abi sensitive places. So its easier to just start from scratch. – Kent Fredric Nov 09 '13 at 23:37

1 Answers1

1

I would just rename C:\strawberry to C:\strawberry-old before installing the new version. Chances are you could just copy modules from the old installation to the new one (not forgetting to look for bits in the "auto" directories). That said, I would probably just reinstall everything from CPAN anyway to get the latest versions. It helps if you have a .bat file that automates this for your favourite additions.

Denis Howe
  • 2,092
  • 1
  • 23
  • 25