I don't necessarily think it should be an "author provides it or none at all" thing.

Agreed. But the motivation of the 'abandon ActiveState move' seems to be primarily driven by module authors who's modules are being flagged as 'unbuildable' by the automated AS process.

I think I can understand why AS do not fix the automated process. It's probably simply one of survival. They are (now again I think) as smallish company with limited pockets trying to survive. Any manual intervention into their automated process--which they provide free to the community with little possibility of return--would be a pure sink on their resources. They are already providing the storage, cpu and bandwidth.

I think that the premise that "they should do more" is flawed. Adding the need for personnel, to manually intervene, to the equation, could make the service and/or company go away completely! I also think that fostering the expectation that large volumes of win32 Perl (corporates and individual) users (as opposed to hackers) will abandon AS for a DIY build it yourself on every machine alternative is forlorn and pointless.

The moves in this direction, like strawberry perl, are motivated by the wish to make things easier for the Perl module developers--which by and large means non-win32 users--rather than the vast majority of win32 Perl users.

Making life easier for module writers to write, build & test their modules on win32 is a strong and good motivation. And it can only benefit win32 users also in the long term, by giving them access to a wider set of modules. But maybe the best solution would to not throw the baby out with the bath water.

If AS could provide a mechanism for allowing volunteer intervention to correct 'broken' automated builds might be one solution. Using CPAN to provide a central repository for binary distributions might be another. I realise that binary distributions can be bigger than a standard module, and that CPAN disk space is neither limitless and is also provided free to the community--and by many mirrors--by generous donations.

But then, there is an awful lot of cruft on CPAN now--stuff that hasn't been updated or downloaded for years if not decades--along with other stuff that probably shouldn't have ever made it up there in the first place.

Then again, I'm the wrong person to be having any of these thoughts--but I have them anyway.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I also think that fostering the expectation that large volumes of win32 Perl (corporates and individual) users (as opposed to hackers) will abandon AS for a DIY build it yourself on every machine alternative is forlorn and pointless.

Vanilla/Strawberry Perl are not "build it yourself". They are just packaged installers. Yes, it's volunteer labor. How does that differ from a Perl RPM or other package from any major Linux distribution? Or any packaged installer for Windows from other OSS projects?

motivated by the wish to make things easier for the Perl module developers--which by and large means non-win32 users--rather than the vast majority of win32 Perl users.

I think you have this backwards. It's motivated by Perl module developers who want to make things easier for the vast majority of Win32 Perl users by freeing them from the shackles of Perl 5.8.1 core modules mandated by the AS build process. The goal is to help users benefit from new or upgraded modules. Most users won't be bothered to try to figure it out a module that isn't available as a PPM could be installed anyway via CPAN -- if a PPM isn't available, they just won't use it.

If anything, it's making module authors' lives more difficult because of the greater number of modules getting scrutiny and bug reports on the Win32 platform. (c.f. Vanilla Perl Problem Modules) Tools like CPAN::Reporter are part of this -- increasing visibility of Win32 portability problems through CPAN Testers rather than leaving it relatively hidden inside a proprietary build system.

-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.

There is a very definite reason not to do this in the general case.

The people who have set up CPAN mirrors are donating their bandwidth and storage. If we started uploading binaries (be it PPM or .par's) of all CPAN modules for all versions of perl and for several OS's, the size of the CPAN archive would explode. That might or rather will be considered abuse.

A further issue is that the distribution of binaries from untrusted sources is a major security issue. Suppose anybody could upload a binary for any module. Madness!

Now, laying these points aside, let me tell you that I am regularily uploading binaries to CPAN. Yes, you read that right. I'm violating my own advice here.

Reason for this lies in the nature of those binaries: They're binary builds of PAR (now PAR::Packer) for win32 only. Mainly, this is because PAR has itself traits of a package manager and providing a binary can mean the user does not need to do fancy bootstrapping to get it to work. This has been relaxed now that PAR was split into two distributions, however. The other reason is that Win32 is one of the major user platforms for PAR and doesn't always come with a C compiler. Furthermore, the security issue is sort of minimized by that those packages are always by the same CPAN user as the release manager for PAR itself.

That being said: Why upload PPM's to CPAN which can only reasonably be used with a single specific distribution of perl? (ActivePerl)
Instead, you could use .par archives and provide support for auto-installing them if no compiler was found. This works well with PAR right now.

Steffen

Yes, you read that right. I'm violating my own advice here.

S'funny how things are okay for 'special cases', when those special cases are close to our own hearts.

The people who have set up CPAN mirrors are donating their bandwidth and storage.

Some interesting numbers. Template::Toolkitv2.15.zip PPM is 494 Kb.

Template::Toolkitv2.15 .tar.gz is 761 Kb.

There are currently no less than 15 versions of the latter being mirrored. Loosing two of those old versions (to say backpan) would allow 3 versions of the PPM to be held without creating any extra demand on the mirrors.

the distribution of binaries from untrusted sources is a major security issue.

Do you inspect every line of every source file in each package you install? What about all the .t files? Does anyone?

Why would you view the authors of source distributions as trustworthy, and those same people packaging those same modules in binary form as untrustworthy? If you have the processes and procedures in place to verify the integrity of your systems when you build a module from CPAN via a source distribution, those same processes and procedures should also be used to detect miscreant binary installations.

There is a pervasive logical disconnect here that says source is safe and binary not. But pervasive does not mean correct. Any and all software sourced from outside your organisation is potentially dangerous. And the idea that all the risks are negated by the potential for visual inspection, even if anyone actually did that--which they don't--is so profoundly wrong, that the idea itself, and those that expound it, should be actively and vigorously countered at every opportunity.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Addressing your remark about special cases: It wasn't me who started doing those binary releases of PAR. I just became responsible for the PAR releases and continued ongoing practice.

Whether 15 versions of Template::Toolkit should be supplied via CPAN is an entirely different question than whether we should add various PPM packages per distribution.

Furthermore, I do know organizations who only allow thoroughly inspected code to be used. But that doesn't matter. It's a question of principle.

Why would you view the authors of source distributions as trustworthy, and those same people packaging those same modules in binary form as untrustworthy? If you have the processes and procedures in place to verify the integrity of your systems when you build a module from CPAN via a source distribution, those same processes and procedures should also be used to detect miscreant binary installations.

That's ridiculous. Disassemble shared libraries? I don't think so. Also, you suggested that anybody should be able to upload PPMs for any modules.

Steffen