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