Re^2: DBD::ODBC vs. DBD::Oracle

"known large problems with lots of standard modules in Activestate's version"?

I've been using ActiveState's (formerly ActiveWare, formerly Hip Communications) Perl since about '97 so I suppose if there were "known large problems" especially with "standard modules" I would be aware of them. May I ask what do you mean?

Jenda
Support Denmark!
Defend the free world!

Comment on Re^2: DBD::ODBC vs. DBD::Oracle

Replies are listed 'Best First'.
Re^3: DBD::ODBC vs. DBD::Oracle by tilly (Archbishop) on Aug 23, 2008 at 15:10 UTC
According to reports that I've seen the default ppm repository supplied by ActiveState does not build Scalar::Util or List::MoreUtils. Which means that it does not include any CPAN module that uses either of them, or depends on something that does. Like Test::More. Which turns out to be about 2/3 of CPAN. And the remaining third isn't exactly the highest quality third. This was the motivation for Strawberry Perl in the first place. And to the best of my knowledge, the problem still exists despite promises to make it better Real Soon Now. But even if they do make it better, the design problem that caused this still exists in PPM, so we can expect it to eventually descend into something like the current mess again some day. For further information see ActivePerl PPM repository design flaw goes critical and ActiveState finally starting to lift it's game.	[reply]

Replies are listed 'Best First'.

Re^3: DBD::ODBC vs. DBD::Oracle
by tilly (Archbishop) on Aug 23, 2008 at 15:10 UTC

not

This was the motivation for Strawberry Perl in the first place. And to the best of my knowledge, the problem still exists despite promises to make it better Real Soon Now. But even if they do make it better, the design problem that caused this still exists in PPM, so we can expect it to eventually descend into something like the current mess again some day.

For further information see ActivePerl PPM repository design flaw goes critical and ActiveState finally starting to lift it's game.

[reply]