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?]
Nope, he did post to both lists.
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.
But it doesn't. Since we want the core to include all the essential modules in the core. If downloading the dependant modules was a trivial thing, the core would simply include them, right?
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.
True, but in this we also have the master package which includes only that thing and nothing else.
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?".
True, but the user might not be aware which one is the right one. And if the server side (the indexer) can provide a non-ambiguous solution in first place, why delegating this to a client, which may be outdated.
[...]
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?
Yes.
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.
For a moment I thought you caught me, but luckily it's not a problem in this particular case. However it can be a problem in other cases.
First of all, perl-core already suffers from this problem. If I install the latest Test::Harness and then upgrade perl, chances are that I downgrade Test::Harness, right?
Second, both Apache::Test and ModPerl::MMHelper (or whatever I'll call it) aren't modules for the end user. The two are needed during the module build/test time. So there is absolutely no problem with the version number. If it's the core build, it already includes a version that it builds and tests with just right. If it's a 3rd party Apache:: module, its PREREQ_PM will specify the wanted versions of Apache::Test and ModPerl::MMHelper which user has to satisfy.
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.
In general case, possible. In my case it doesn't.
I just still too vividly remember the agony of getting perl 5.6 fetched and built when you want to install some module for perl 5.005_03 ;)
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.
That's correct. Perhaps its doc could add a warning, since I'm sure many people won't think about it (just like I didn't ;)
Thanks Ken.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
