Randy Kobes wrote:
On Sat, 1 Feb 2003, Stas Bekman wrote:On Sat, 1 Feb 2003, 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.That's true - I was thinking of cases where both versions are available, but this can be done thru environment variables.
I think the logic should be: - If only one version is available go straight for it. - If there are both: - If MOD_PERL2=1 is set, go for it - otherwise prompt user
True,However, for CPAN.pm, 'use Apache2' wouldn't normally be done so
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.No, 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: 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's true ... What I was thinking about PERL5LIB was that
CPAN.pm, when looking for installed modules, won't normally
search under Apache2/, and thus won't be able to recommend
upgrades if available. That again could be handled via
environment variables (PERL5LIB, and MOD_PERL2 or MOD_PERL1), and calling the CPAN.pm shell appropriately, as you say.
perl -MApache2 -MCPAN -eshell
should be sufficient. PERL5LIB is going to be too messed up to explain to other people, because of the arch-platform-multi-ithreads thingies ;)
Yes, but 'r' will suggest an update, which should lead to an update of whatever you've configured.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.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.That is a drawback ... Specifying MOD_PERL1 or MOD_PERL2 would at least specify which version to install ...
__________________________________________________________________
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]
