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

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

Randy Kobes wrote:
> 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 <stas@xxxxxx.xxx> 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: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