3. once the disto with both versions is downloaded users will still have to choose which version to install. Meaning interaction with MakeMaker. Each author will implement it differently leaving users with consistent interface. Since that interaction (or some other env var, special options to MakeMaker) are unavoidable, it's much better to implement on the CPAN/MakeMaker client side which will enforce a consistent familiar interface across all modules.
The selection of which to build/install could be abstracted into a module that's a prerequisite for these combined distributions.
Yes, I thought that it will work but there is a problem with it. Going back to the mod_perl example. The idiom of checking the version number is:
require mod_perl;
if ($mod_perl::VERSION) { ... }
else { ... }So the version has to be maintained in mod_perl.pm. Now let's say that v1 ships with Apache.pm and v2 ships with Apache2.pm. The problem is that mod_perl.pm is the one that contains the version number. So you can't make a dependency on a particular version of Apache2.pm, because it doesn't contain that version. Ideally PREREQ_PM should support:
mod_perl => [ MIN, MAX_MINUS_ONE ],
in addition to the existing rule:
mod_perl => MIN,
So if my module requires at least mod_perl 1.26 but won't work with 2.0, I should be able to pass in PREREQ_PM:
mod_perl => [ 1.27, 2.0 ],
Notice that my spec introduces MAX_MINUS_ONE, which means '< MAX'
Now let's say PAUSE has the following versions: 1.27, 1.28, 1.29, 2.0 and 2.01. Based on the above prerequisite CPAN should select 1.29. If the prerequistite is:
mod_perl => [ 2.0 ],
or:
mod_perl => 2.0,
CPAN should fetch 2.01.
Do you think this is hard to implement? I understand that Module::Build already supports something similar.
I'm sure we can come up with several other problems with this approach.
Probably. I didn't say it was perfect, just the only practical solution I could see that would work in the short term for users who haven't/won't/can't upgrade their perl/CPAN code.
Let's say that this is not a problem. If people want to have better things they should will to upgrade things.
Also don't forget another related problem I brought up a few months ago on p5p. Libraries like GD, have several reincarnations existing at the same time. And it's left to the user the drill of manually going to cpan.org and picking the right reincarnation, by wading through 50 or so readme files, trying to figure out which is the right version to choose. I don't want to mix this problem with the more critical issue discussed in this email, but this is something that needs to be on the chart of the things that need to be fixed.
Solutions and patches welcome, from anyone.
I've been trying to come up with solutions for a long time. I don't think it's a problem of tuits to do the actual implementation. I have suggested to fund a project to resolve those problem. But before it can be funded it needs to be spec'ed out. But I keep on getting 'not in the near future' and similar answers :( Last time, this issue was discussed at p5p meeting in Paris, it was decided that it'll be resolved at the CPAN meeting in Oct. But it wasn't.
I wish it was something that was a bother only to me personally. I can go to CPAN and manually get what I want. The problem is that it's a big bother with a huge community of mod_perl users. And all complaints end up on the mod_perl developer's table. And the ball hasn't even started to roll yet. It will soon. It's not going to be pretty.
__________________________________________________________________ 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
