Stas Bekman <[EMAIL PROTECTED]> writes:
Randy Kobes wrote:
[...]
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.
I'd like to see that -1 backed up with a technical objection;
lots of people are saying that "very confusing" isn't a satisfactory
explanation.
OK, here it is the same thing, worded more technically:
We can't have mod_perl.pm and mod_perl2.pm in the same distro. There should be only one API and not two that do the same thing.
The advantage of the additional mod_perl2.pm package is that it is indexable in parallel with the existing mp1 tarball.
For mp2-only products, this would seem to be an advantage because
they now have an easy way of asserting that fact in their prereqs. mp1-only products would need a way of saying "hold on, I'm not mp2
compatible yet!", which is something a test suite or a load-time check will take care of. Cross-compatible products would be unaffected.
What's the downside? That folks listing mod_perl 1.99 as a prereq can't be satisfied? That's something that may change in the future,
so I'm not worried about that problem.
Sorry, Joe, but that's not enough. If you do mod_perl2.pm. You will need to add APR{X}.pm and do the same for all 3rd party modules. Please stop concentrating on the modperl-core and try to address the problem as a whole.
We will end up with some code requiring mod_perl.pm and other mod_perl2.pm.
That's ok with me.
See above.
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.
Err, but then folks would need to adjust their prereqs (from say "Apache::Resource" to "Bundle::mod_perlX"), right? Why do you see this as preferable to the mod_perl2.pm solution?
I've explained why in the last sentence above. It's clear that it's not part of the API, whereas mod_perl.pm is a part of the API.
-- __________________________________________________________________ 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
