I could see the standard response to questions about build problems of packages on win32 being "it works with Vanilla Perl, so it must be Active State that is broken", which wouldn't help many users.

It wouldn't help many users of ActiveState Perl, you mean. If ActiveState is broken and something else works, isn't that an improvement for users in general? Maybe some friendly co-opetition would improve ActiveState, too.

As to the Scalar::Util thing -- it has more to do with the fact that ActiveState's auto-build procedure uses their earliest 5.8 Perl release as the the basis for PPM generation without any upgrades to any modules in core. 8xx PPM's are supposed to be ones that will work with the earliest 5.8 Perl released by ActiveState -- which was several years ago. So anyone depending on ActiveState-built PPM's has to accept a 3-year lag in compatibility.

It's compounded by the fact that Perl can't easily replace core modules on Windows if they are in-use. demerphq has recently patched ExtUtils::Install to use the Win32 API to do this on Windows (and the old files are removed at the next reboot). That's great news for VanillaPerl, but doesn't help ActiveState as, again, they're stuck with ExtUtils::Install from 5.8.0.

The inability to rely upon any upgrades to core modules in 5.8 is a major flaw in my opinion. I'm sure there have been substantial bug-fixes to numerous core modules from 5.8.0 to 5.8.8. But any distribution that depends on certain behavior of upgraded modules will fail a dependency version requirements checks for building a PPM or may not behavior properly if the dependency version is ignored.

A good example of that is File::Spec and company. Look at the Changes file and look at how many Win32 bug fixes there have been in the last year alone. There are a lot. Any any code which relies upon those bugs being fixed can't require a modern File::Spec and still pass ActiveState's PPM build process.

The point is that this is not "standard version control ripples" as you put it. This is a fundamental difference in the philosophy of module packaging, distribution and support. Both are valid and they just serve different "customers" who have different wants.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

In reply to Re^4: [JOB] The Perl Foundation seeks Windows Developer by xdg
in thread [JOB] The Perl Foundation seeks Windows Developer by adamk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.