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. > > 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. > > > 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 ... -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
