When ActivePerl was first released, there was no way to install XS modules from CPAN, making CPAN almost entirely useless on Windows.
The solution was a good one, build a machine to generate distribution-specific binary packages out of each source package on the CPAN, and provide an installed for those instead.
They got remarkably good CPAN coverage initially, and the gatekeeper responsibility was one they fulfilled competently.
Unfortunately, things started to go a bit pear shaped during the 5.8 timeline.
The need to maintain binary compatibility and upgradability for PPM packages meant that bugs started to creep in that didn't have any impact on regular CPAN users.
For example, because PPM implements an RPM'like model (like many binary packages) of a file only being able to exist in a single binary package, it meant that the concept of dual-life modules became a problem.
You couldn't install an upgraded CPAN version of a module, because that would violate the integrity of the core package.
In 2005, this bug meant that I was unable to install the ultra-shiny PPI::Tester demo/debugging program on my own laptop for my OSCON PPI talk, despite the fact the code would all work just fine on Windows.
For the first time, the packaging system got in the way of something I wanted to do. After almost a year of trying to work to get the flaws in the PPM repository fixed, I was told that it simply wouldn't be fixed at all (for corporate/legal reasons I won't try to detail, in case I phrase it wrong).
This problem with weaken expanded to include anything that had an explicit dependency on a new version of Scalar::Util, recursively.
I had hoped that with 5.10.0 ActiveState would be able to drop the legacy issues of 5.8.0 and start fresh with near-full CPAN support.
Unfortunately, this has not been the case.
In fact, it is now so bad as to no longer be of any practical value at all.
The key problem here is that the PPM repository engine, on Win32 at least, refuses to allow you to make a dependency on a dual-life module, shortcutting to FAIL even if 100% of tests pass for the module.
Test::More is one such dual-life module that the PPM repository builder will give you an automatic FAIL result for depending on.
If your CPAN module has a dependency on Test::More, you cannot install that module on ActivePerl out the box.
No Template Toolkit, no mechanize, no POE, no test modules that themselves use Test::More.
In fact, only 35% of CPAN remains available via the PPM repository, and from what I can see looking through the list of what's left, it's mostly the third of CPAN that has no tests or no intrinsic value.
You either have to switch to an unsupported PPM repository, most likely the Kobes PPM repository, or you have to install a compiler toolchain on top of ActivePerl and use CPAN directly.
In fact, even the Tiny modules (which generally only have a dependency on Test::More from 0.47, from an age ago) are not available via PPM despite passing all tests.
Looking at the list of what is available, I can't see more than 1 or 2 modules that I have ever used, and none that I use regularly.
Not a single one of my modules of any use whatsoever is available on ActivePerl. Just a couple of Acme modules and a couple of Test::Dummy modules.
The highest rate of PASS results, in fact, appears to be in the Acme:: namespace where modules are more likely to have no tests.
And to add insult to injury, the PASS rate on platforms OTHER THAN Windows is much much better. It's only their main platform, with 5000 downloads a day, that they cripple CPAN.
For the most stark example, take a look at this link.
http://ppm.activestate.com/BuildStatus/5.10-T.html
The situation is now so bad, there is NOT EVEN ONE single module beginning with the letter T that passes on the ActiveState PPM build system. None. Zero.
Want to use any module beginning with the letter T (other than what comes in the core)? Too bad.
Given T includes Test:: I have to conclude that nobody at ActiveState is actually dog-fooding their own Perl distribution by running the out-the-box Windows version any more.
Because the PPM repository has now become almost entirely useless.
I really really hope this is just a bug they can fix...
Looking at Math::BigInt::GMP, there seems to be a big problem. If it can't find XSLoader, a core module, there must be some big problems with the build process.
