develooper Front page | perl.perl5.porters | Postings from March 2003

Re: rfc: a generic solution for dual-life CPAN packages

From:
Stas Bekman
Date:
March 26, 2003 16:03
Subject:
Re: rfc: a generic solution for dual-life CPAN packages
Message ID:
3E823F50.5070005@stason.org
Ken Williams wrote:
> 
> On Tuesday, March 25, 2003, at 09:43  PM, Stas Bekman wrote:
> 
>> Currently CPAN.pm has a special logic to make sure that if a requested 
>> package is found in the core perl distribution and in another package, 
>> that another package takes the precedence if its VERSION number is the 
>> same or higher than the VERSION number of that package in the core 
>> perl distro.
>>
>> Now I working on a helper package for mod_perl CPAN modules (to reduce 
>> the craft in Makefile.PL) and I want it to be on CPAN, but also 
>> include it in the mod_perl 1.0 and 2.0 core (also living on CPAN). I 
>> foresee a problem with CPAN.pm, as it's going to see the same package 
>> in 3 different packages and which is going to be picked by CPAN.pm is 
>> undefined, since we have no special case logic for mod_perl-core 
>> packages. And we don't want CPAN.pm to try to install mod_perl 1.0, 
>> when I just want to fetch that single package.
>>
>> [snip]
> 
> 
> My recommendation would be to not include the helper package in the two 
> core packages, and to just add it as a dependency.  Even if CPAN were 
> changed in the way you suggest, it wouldn't work properly with people's 
> stock CPANs, and it seems bad for mod_perl to depend on a certain 
> version of CPAN.

As Andreas correctly points out, it's the indexer thing, not the client 
CPAN.pm or CPANPLUS. So this change is transparent to users having whatever 
version of CPAN/CPANPLUS they have.

First of all this is a more generic problem than in my particular case, we 
already have this problem with all packages living in the core and separately 
on the CPAN. The indexer introduces a special case for perl core. Now think of 
the mod_perl distro, as the perl core distro, do we introduce a special case 
here? And if tomorrow a new big distro needs this functionality, do they ask 
for a special case as well? That's too much of a hassle for Andreas IMHO.

Back to our particular problem.

We want to minimize the dependencies to zero, so a user downloading mod_perl 
already has all the critical packages. The reason I want to redistribute some 
of these packages separately on CPAN is for mod_perl 1.0 users, so they can 
download these packages without needing to install mod_perl 2.0.

In particular we have the Apache::Test suite which lives in the mod_perl 2.0 
source distro, but since it also works with mod_perl 1.0 or any Apache module 
(C/Perl/PHP/etc), it should have its own life on CPAN.

Now I'm working on a new module for CPAN 3rd party Apache:: developers, which 
should make the writing of Makefile.PL's a much easier task, which is 
currently not simple at all if your module has XS and needs to support both 
version of mod_perl, and different testing suites (Apache::test and 
Apache::Test). So I was planning to include this module in both mod_perl 
distros and on CPAN separately, so those with older mod_perl versions can 
install it via PREREQ_PM.

While we can suggest using CPAN::MakeMaker for the latter case, since this 
module is going to be small. Apache::Test is a big package (50k tar.gz) and 
bundling it with every Apache:: CPAN package would be a waste of space and 
bandwidth.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About