Randy Kobes wrote:
You know that interactive installs are best avoided if possible. If we do it right, only for the build of mod_perl from CPAN you'd need to tell where apxs or the includes dir is, which I think can be controlled from the env vars as well.On Sat, 1 Feb 2003, Stas Bekman wrote:I've UNINST=1 set in my CPAN/Config.pm, so that older versions will be automatically cleaned up. Now that means if I install mod_perl 2.0 or any 3rd party 2.0 modules, the 1.0 version will get uninstalled. In case of mod_perl 1.0, it'll be uninstalled only partially (since it uninstalls only the same filenames that it's installing). Another problem with CPAN is that it would be impossible to upgrade 1.0 modules, if the corresponding 2.0 versions will be on CPAN :(I'm not sure about this problem for mod_perl itself, but perhaps one way to address the problem of 3rd party modules (with both mod_perl 1 and 2 versions) is for authors to distribute the modules in the same distribution and then adopt a convention to arrange for the mod_perl 2.0 modules to be placed under Apache2/. The user can then (interactively) install either one (or both)
That's where ModPerl::MM::WriteMakefile kicks in, it will handle all this automatically.versions without affecting the other (I'm not sure about this for modules with xs components, though).
I can't test whether installing mod_perl 2.0 will delete 1.0 with UNINST=1, because CPAN doesn't index non-released modules ('_' in the version).
However, for CPAN.pm, 'use Apache2' wouldn't normally be done soNo, no, Makefile.PL of the module should do it by itself. (See my other email, I've posted after this one). I think the env var should do the trick. you can even create convenient aliases for this, if you don't want to set things globally. So whenever you want to use CPAN for mod_perl 1.0 you'd call:
as to adjust @INC to see the installed Apache2 modules. Perhaps
PERL5LIB would have to be set by the user, which isn't great - if
it was a simple thing, perhaps Andreas might include such a
functionality in CPAN.pm.
alias cpan-mp1 perl -MCPAN -eshell
and for 2.0 you'd have:
alias cpan-mp2 MOD_PERL2=1 perl -MCPAN -eshell
That's why I was talking about using a common way to tell Makefile.PL what version we are building for. If we (3rd party module developers) all confirm to it, than things will be really easy.
That should work. The only drawback is the following: Let's say you've a stable version of your module for 1.0, but you do lost of new releases for 2.0. If you have a unified version number for 1.0 and 2.0, 1.0 users will be prompted to update their module even though nothing has changed for 1.0.Another thing, as you mentioned, is the version numbering used by CPAN.pm to recommend upgrades. Assuming the module name is the same for both mod_perl 1 and 2 versions, what might work, if the author has both versions in the same package, is for the mod_perl 1 and 2 version numbers to be synched when an update is made.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
