On Wednesday, March 26, 2003, at 06:01 PM, Stas Bekman wrote:
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.
I see. [I think I missed Andreas' message on module-authors, maybe it was only to p5p?]
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.
For what it's worth, my solution to that problem would essentially be the same as what I recommended in your case: for core modules that are in CPAN independently, the core should essentially "depend" on the CPAN versions.
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.
So it looks like the issue is that we want a way for a module to appear in more than one distribution. From a packaging (dpkg, etc.) standpoint, I think this is often solved by saying that a particular package "provides" a particular functionality. For instance, several different packages may provide a mailer. But what do you do if you want to install a mailer but you don't know which package to get it from? I'm not sure this case is usually handled. The user usually has to choose manually.
Ideally, I think, CPAN or CPANPLUS would tell the user "the requested module is available in the following distributions, which one do you want to install?".
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.
That sounds reasonable.
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.
And you're proposing that the CPAN version is the primary one, right?
Inevitably there will be version sync issues, unless you release a new mod_perl every time its bundled modules are released. For example, will it be possible for a user who already has, say, Apache::Test 0.14 installed to download and install mod_perl, which includes Apache::Test 0.12, without backporting? And does this lock you into endless rigid backward compatibility? It seems like it does.
I'm not trying to poo-poo the idea, but I do think it introduces some complexities that aren't present in a simple X-depends-on-Y and Y-is-only-provided-by-distro-FOO model.
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.
I tend to think that CPAN::MakeMaker introduces the same kinds of problems I've outlined above.
-Ken
