Offer Kaye <[EMAIL PROTECTED]> wrote:
> Just an example, IO::All [1] version 0.33 has been available since Dec
> 17, 2004. It passed testing many times, at least according to its
> testers page [2]. My default 5.8.7 ActivePerl distribution lists
> IO::All version 0.17 .
According to
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/IO-All-0.33.txt
it is not being built because Spiffy failed it's tests. According to
Spiffy's log, *it* did not build becuase Scalar-List-Utils failed to
build... Which is the same module that both Adam Kennedy and David Golden
are complaining about. (I wonder how many modules are being held back over
this one bug?)
> I'm not sure which of the reasons you listed are valid, as a user I
> have no real way of knowing... that's why I thought an automated
> Windows-PPM sub-domain on CPAN which would be updated automatically
> for every new package would be great. What you are saying, that
> ActiveState already have such a system, is news to me, especially in
> view of examples such as the above... I would rather use CPAN, but the
> PPM works fine for me, only it's not as updated as CPAN.
I think it's a combination of "too much to do, too little time" and
the QA philosophy of ActiveState. On ppm.activestate.com, if the unit tests
fail, you don't get a PPM; I guess this "protects" ActivePerl users from
installing modules that won't work properly on their install.
ppm.cpan.org would be a good idea and probably not too hard to
implement. What would it's mandate be? Provide every package out there, even
if unit tests fail, so long as it acutally built? Who is going to provide
the icky sticky windows box with VC++-compiled versions of all the libraries
people expect to be able to use with perl (libgd, libmysqlclient,
apache2, etc)? I certainly don't want to lay my hands on any windows box.
;-)
> I'd like to clarify something - I don't really expect Gozer to handle this
> problem... or a problem with any other module... there are so many, how
> can a single person keep up? It would be better if the system were
> automated... and worked :)
I think if the module is close to the metal and a lot of other
modules depend on it, it would be worth ActiveState's time to investigate
the problem and either fix the build system or fix the module. It's a big
payoff if fixing one module means that all of a sudden another 30 or so
automagically build.
> I would rather not use 2 seperate package installation schemes...
> either CPAN or PPM (or something else), not both.
I think those two schemes are exactly what we need for perl. It's
analogous to building and installing a source package, or just installing
the latest RPM/.deb/whatever.
- Tyler
