Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

[prev] [thread] [next] [Date index for 2004/12/31]

Joe Schaefer wrote:
> Stas Bekman <stas@xxxxxx.xxx> 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:stas@xxxxxx.xxx 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