Hey, I'll cop to working with Activestate Perl on Windows! I've installed a number of modules, both with Makefile.PL/nmake and with PPM. While I haven't hosed an otherwise working install with a muffed PPD dependency, I'm sure it's possible. That's an essential problem with package-based installs, IMHO.

I have found that, with PPM3 and Activestate Perl 5.6 (so my Win32::AdminMisc PPD installs cleanly... it's more for the sanity of the other NT admins), I have had no issues. But, as long as I'm installing PPDs, I'm at the mercy of the maintainers. Cygwin isn't a bad option, either. It's just not the one I use in production for Perl on Win32. Ditto the non-Activestate Perl for Win32.

As for the purpose of PPM, I think Activestate was hoping for adoption of PPDs across the OS landscape. They've had a Redhat install for a long time, though I've never even been slightly tempted to try it. It's not an awful idea (after all, I use it... I use RPMs, too, usually with Apt for RPM... maybe I'm more of a devotee of packages than I think ;), but in an ideal world, I'd nmake every module on every system.

Is there an easy way to detect PPM vs. CPAN? Sure. You'll be calling the PPM utility to install PPDs. Otherwise, at least on a non-Cygwin Win32 system, you probably aren't using CPAN. You might be, by Hanky, because we're a resourceful lot. But the odds are against it. So, at least there's no ambiguity.

Should module authors take action? As mentioned before, PPM is Activestate's deal. If you're Dave Roth, Jenda Krynicky, Jens Helberg or another of many good Win32 module builders, you're probably rolling your own PPD anyway. It would be great if all modules worked on Win32, but that isn't practical. I'd say modules directed at Win32 targets should consider PPD building, but I'm just as happy that they build good, useful modules.

On that note, thanks to everyone who has ever developed a module. I may not have used it (or used it well), but I owe you anyway!