Stas, that was a a very useful summary of the issues - thanks for putting that together!
:)
On Fri, 31 Dec 2004, Stas Bekman wrote:
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...] I now think was a mistake for any of the Apache::* core modules to be indexed with mp1, because it looks like a wedding between the Apache:: APIs and the mp1 implementation of them. This is, IMO, the kernel of the complaints against the mp2 release plan.
It has nothing to do with indexing of mp1 Apache::* core modules. When Randal has it's finger glued to the 'r' button, CPAN shell checks what are the *installed* modules and compares their version against the index. So if mp1 didn't index any of those, but mp2 did, you will still have a problem. Perhaps you were suggesting that none of the Apache::* core modules, but mod_perl.pm, should be indexed (both mp1 and mp2), in which case it makes sense.
You still have a problem with mod_perl.pm.
To (partially) get around this CPAN.pm 'r' problem of recommendations of available upgrades, what about, in the mp2 package, use a no_index in META.yml to tell PAUSE not to index the mp2 modules that have the same name as mp1 counterparts:
Apache::Log Apache::PerlSections Apache::Resource Apache::SizeLimit Apache::Status Apache::URI Apache::Util
That would mean in a Makefile.PL prerequisites section that one couldn't use these to specify an mp2 version, but that's perhaps not too much of a problem, as there's other mp2-specific modules that can be used.
To start with, are we really interested to workaround for the mp-core, ignoring the identical problem with multiple 3rd party modules? I fail to see how providing a workaround for the core, relieves the problem, as 3rd party modules (which are many more than the core) will bother users just as well.
There's still mod_perl.pm in both packages, though. In mp2,
this is just something to define the version, and also to
provide a NAME pod section (if I remember correctly, this
was inserted for the benefit of search.cpan.org, to get an
abstract for the package). Not indexing mp2's mod_perl.pm
shouldn't affect search.cpan.org (I believe), as it
doesn't rely on the PAUSE indices, but it would
mean that one couldn't use (the useful)
PREREQ_PM => {mod_perl => 1.99}
in a 3rd party Makefile.PL to specify mp2. Instead, what
about adding a mod_perl2.pm to the mp2 distribution, just
again defining the version, so that one could use
PREREQ_PM => {mod_perl2 => 1.99}
mod_perl.pm would still be provided in the mp2 package
(just not indexed by PAUSE), so that constructions like
if ($mod_perl::VERSION > 1.99)
would still work.
-1, that will be very confusing as people will start using it for other things. We will end up with some code requiring mod_perl.pm and other mod_perl2.pm.
The use of a Bundle in a prerequisite is similar, but the thing with those (if I understand the usage correctly) one must explicitly specify a package version to use, so that if a later version of a package is released, one must update the Bundle file to use that package, if desired.
The idea was to have the Bundle included in the same distro, so when a new mod_perl.pm is released, the Bundle will be updated too. I prefer the Bundle workaround vs. mod_perl2.pm, since the former makes it clear that it's only a CPAN thing and not to be used at the real code (other than in prerequisite hash.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
