Historically, though, these links reflect what I’ve seen of ActiveState’s PPM:
http://ppm.activestate.com/BuildStatus/5.6-T.html
http://ppm.activestate.com/BuildStatus/5.8-T.html
I’m just singling out the T’s because many of those Test:: modules happen to be important to me and I’ve had mixed results over the years getting the CPAN sources built on win32 via ActiveState Perl.

Adam also indicated in his talk that Vanilla and Strawberry Perl will help shorten the feedback cycle in order to get more attention on win32 specific issues in modules. And this is really what needs to happen rather than hoping Activestate will shoulder the entire burden of CPAN on win32.

Why, if these things supposedly just work, do Adam and Ovid have such trouble getting things to just work?

Again, I don’t use Windows and I don’t use ActivePerl. I have been a Linux user for over ten years and feel very uncomfortable when using Windows, so I’m not the right person to say what’s right or wrong with ActivePerl. However, both Adam and Ovid have had quite a bit to say about the frustrations they’ve experienced with it.

The URL to our beta repository seem to have gone missing; it was supposed to be http://ppm.activestate.com/beta/

However, my strong belief in Free Speech led me to post it, even if I don’t agree or care about it.

Regardless of how proactive ActiveState is at defending ActivePerl, the fact that Strawberry Perl and Camelbox even exist, along with some of the issues I’ve seen Ovid have with the build system, tells me that something actually is wrong with it. My understanding is that, when people have gone to ActiveState for support, they don’t receive any. We’re the Perl community, and we’re good at getting things done.

Claiming that PPI and other modules depending on List::MoreUtils do
not work in ActivePerl isn’t accurate. What’s true is that the free
repository ActiveState has provided for PPM packages built from CPAN
has not been able to provide a pre-built List::MoreUtils and therefore
not a pre-built PPI because of technical compatibility issues. Even
if our PPM repository did not provide these packages, you could easily
install them from other PPM repositories or use the CPAN shell the way
Strawberry Perl now supports. There is nothing in ActivePerl itself
that has made it unsuitable for running these modules.

ActivePerl has supported out-of-the-box module install from source via
the CPAN shell for users that had the free MinGW compiler installed
for almost 3 years now (since our 815 release).

I’m also glad to say that the problems with our PPM repository will
soon be history, and that you can already install PPI without problems
from our new PPM repositories, currently in beta at
. The beta repository currently
contain about 2000 additional Windows packages compared to the old
repository. The built system for the new repository is a complete
rewrite where we let the CPAN shell do most of the hard work, giving
us a system with much higher success rate and one that puts up
pre-built packages usually within a day after they have been published
to CPAN. We are quite exited about it and we hope our ActivePerl
users as well as the Strawberry Perl users will find it a useful
service.