in reply to Strawberry & ActiveState

XS modules are not binary compatible between perl versions. You need to recompile. Using the autobundle method to migrate from AS to Strawberry could be advantageous. History/Changes has a per version breakdown of changes, I don't know anywhere that shows all differences between X and Y versions.

Replies are listed 'Best First'.
Re^2: Strawberry & ActiveState
by kel (Sexton) on Apr 28, 2020 at 22:29 UTC
    Thank you!

    autobundle seems to be a great solution to this problem.

    BUT....

    It is in package\sformat format:

    ACH::Generator 0.01

    And looking through the docs, there are no options to update to the latest version!

    (Mind you there are 37000 packages in that bundle)

    so

    perl -MCPAN -e 'install Bundle::Snapshot_2017_11_30_00'
    Might take months without a 'notest install'.

    Will CPAN automagically choose the 'right' version for the Strawberry release?

    Now... I do have a CPAN mirror from my Linux drive which is accessible in Win, and can hopefully speed up the process some. Any quick links to using a local mirror? File//path in the config file?

    There is another way, but a bit more tedious. I can take the automirror file, split on \s and just have the package names per line.

    Once upon a time there was a command for retrieving a list of modules that were NOT installed compared to the 'full' CPAN list.

    If I run uniq against the two lists, it can save alot of time by not trying to install modules already installed.

      It doesn't make any kind of sense to try to install everything on cpan, unless you are contributing to cpantesters, which you can't be using the no test option. Installing hundreds if not thousands of modules on a system that is by any definition modern in terms of hardware will not take months. ACH::Generator hasn't had a release since 2006. You could be spending time building modules which no longer work with modern perls, or libraries upon which they depend. Look at the cpan options, you can upgrade modules that.you already have easy. Modern alternative such as cpanm are faster than cpan at straight installs, but do not replicate all features such as bundle support. cpm is much faster than cpanm, I've not tried it on Windows yet. Are you really making use of 37,000 modules? Sire a local mirror helps, perhaps you should only install modules when you find you don't have them installed, this seems like a better use of your time.

        Actually, I am a bit more selective in my Linux system, where I do leave alot out, with my mirror as a source. But it, as a development system which I try to make fully usable *offline* is heavily loaded so as to run or compile virtually anything.

        The Win7 system is a bit different in design, but when I seen how sneaky the ActiveState PPM system was, I decided to go whole hog, and just install everything for the day when they decided to paywall everything, as they are doing now by trying to deprecate PPM snd not doing any noticeable updates in quite some time. I would actually do a bunch of pruning to any 'uninstalled' list to get rid of cruft like AWS, CGI, Locales, and modules for proprietary services and utils. I dont mind older modules, as I have a collection of thousands of perl scripts that I dip into to use as templates for projects I might need at a whim. And I typically want to be able to use their modules. As well as use the Site dirs as a library. Its easier than going through CPAN or ls -lr and trudging through the Author dirs.

        Its how I learn Perl, and other languages. Reading books doesnt seem to sink in.

        So heres my issue: I can chop down the autobundle easily enough (to say, around 10,000). But the darn thing has version numbers. Will it install those *old* versions? If so, I can take the file and process it to just get the modules names, parse them into blocks of 250, and send a block at a time to CPAN. (After removing existing duplicates).