You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/02/01 00:58:31 UTC
CPAN.pm and UNINST=1 for 2.0 and other problems.
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 :(
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Posted by Stas Bekman <st...@stason.org>.
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
>>>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.
True,
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 ;)
>>>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 ...
Yes, but 'r' will suggest an update, which should lead to an update of
whatever you've configured.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> 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)
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.
> versions without affecting the other (I'm not sure about this for
> modules with xs components, though).
That's where ModPerl::MM::WriteMakefile kicks in, it will handle all this
automatically.
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 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.
> 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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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)
versions without affecting the other (I'm not sure about this for
modules with xs components, though).
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. 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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org