On Mon, Dec 22, 2003 at 01:38:17PM -0800, Stas Bekman wrote:
The automatic tools don't *have* to: they're *told* which product to install by a human, no?
No, they aren't. In PREREQ_PM in Makefile.PL you specify the minimal version of some module, CPAN/CPANPLUS will bring the latest version which could be quite a wrong choice if there are two generations of this module on CPAN. Here is an example:
PREREQ_PM => { "Apache::Scoreboard" => "0.12" }
what you get back? 2.01. Right? No.
Which sort of *makes* my point: they're *two separate modules*. They're not 2 different versions of the same module.
Yes and No, depending on how you look at it.
I believe you've missed my point:
The way you're doing it, you will have exactly that problem.
If instead you name your new apache2 compatible thing Apache2::whatever (*even though the internal naming it carries may be apache:: for functionality's sake) then they won't conflict. And if the internal naming depends on the external naming be right, then you have, so far as I can see, a semi-insoluble problem.
Nope. That's a very bad idea. I don't want to go and rewrite all my code to use Apache2::Request and dozens of other modules, which work exactly the same as before, but their guts are different.
I *did* say to only change the name on the packaging, no?
Right. Sorry.
Also I've just released Apache::VMonitor 2.0, which works with both mod_perl generations. So should it be called 1.0? 2.0? It just doesn't work.
If it doesn't depend on the major version of the parent, then this entire conversation doesn't apply to that module, no?
It does if you suggest to deduct which version this module is designed for from its version number.
<sigh>
*You* are suggesting that.
*I* am suggesting that you deduce it from the *name*. I am saying that you *cannot* reliably deduce it from the version number, precisely because you are *overloading* the version number, giving it semantics it should not have.
OK, right.
The point of my comment in the original announcement wasn't start this thread again, but to get things done. The issue with your suggestion is that nowadays we hardly ever do things manually, because we use search.cpan.org or CPAN.pm to tell us what and where the package is and they will fail to do that the way things are today.
Here is what needs to be done:
- META.yml needs to support a new key: product_generation, so module authors can mark their module with the generations their module support. it should be a key/val thing:
product_generation:
mod_perl: 1.0a module can define several generations.
- PAUSE indexer needs to index the higher version number for each product_generation if such exists and not just the highest number.
- search.cpan.org/CPAN.pm/CPANPLUS aka CPAN clients need to present the highest numbers of all available generations, unless you have asked them for a specific version. So whenever you ask any of these CPAN clients to give you Apache::Scoreboard, they should say,:
oh, dear, looks like I have several matches for this module:
version generation Apache::Scoreboard 0.10 mod_perl 1.0 Apache::Scoreboard 2.01 mod_perl 2.0
which one do you want [2.01]?
- since we don't like propmts CPAN clients should be instrumented to let us tell them what's our preferred generations are. I'm not sure about search.cpan.org, but for CPAN.pm/CPANPLUS I want to be able to tell these tools about my preferences. So if I'm going to build 3rd party tools for generation 'mod_perl: 2.0', I'd like to start CPAN.pm like so:
% CPAN_GENERATIONS="mod_perl: 2.0" perl -MCPAN -eshell
or similar.
- PREREQ_PM needs to support ranges, like Module::Build prerequisites do. So if Apache::VMonitor for mod_perl 1.0 needs Apache::Scoreboard for mod_perl 1.0, it can ask for it:
PREREQ_PM => {
"Apache::Scoreboard" => "> 0.12, < 2.00",
}-------------------
Once all the above is done, authors will need to release updated packages to include the updated META.yml with the right generation numbers and Makefile.PL PREREQ_PM fixes. And we are all set.
p.s. remember that the discussed issue is *not* a unique to mod_perl problem. There are several other modules with the same issue. For example GD, which has at least 3 generations on CPAN.
__________________________________________________________________ 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
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
