rfc: allowing more than one mod_perl install - s/Apache2.pm/PREFIX+blib/

[Stas Bekman <st...@stason.org>]

The problem:

You can't have more than one mod_perl 2.0 installation under the same perl 
tree. So if you want to have a threaded and forked mpm builds you need two 
perl trees, or you need to mess with PREFIX for the second installation and 
are still end up in trouble, since you may get modules from the main tree 
getting loaded (while built for a different mpm). Moreover if you have two 
installs, you can't have two sets of executables (e.g. the new mp2bug script).
The same problem extends to 3rd party module builds, you can't have more than one.

The proposed solution:

Ditch the Apache2 coexistance workaround altogether and install each mod_perl 
into its own PREFIX, preferabbly outside the main perl tree. Suggested default 
is /path/to/httpd2/modules/perl, so we have:

/path/to/httpd2/modules/perl/lib
/path/to/httpd2/modules/perl/bin
/path/to/httpd2/modules/perl/include
/path/to/httpd2/modules/perl/man

This solution requires no extra logic during the build time, since we simply 
use the PREFIX MM argument. It also makes the mod_perl installed base self 
containing.

mod_perl.so will have a hardcoded @INC addition, ala libperl.so, so once you 
load mod_perl.so it'll already have @INC adjusted. So no extra manipulations 
on users behald are needed. If users decide to move the tree after the 
installation they will have to adjust PERL5LIB to have the new pathes added.

The only issue with 3rd party modules builds. They can use -Mlib=$PREFIX/lib 
to reach the mod_perl perl tree and should install themselves under the same 
tree (all they need is to reuse the same PREFIX).

__________________________________________________________________
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: rfc: allowing more than one mod_perl install - s/Apache2.pm/PREFIX+blib/

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:
> 
>> The proposed solution:
>>
>> Ditch the Apache2 coexistance workaround altogether and install each 
>> mod_perl into its own PREFIX, preferabbly outside the main perl tree. 
>> Suggested default is /path/to/httpd2/modules/perl, so we have:
>>
>> /path/to/httpd2/modules/perl/lib
>> /path/to/httpd2/modules/perl/bin
>> /path/to/httpd2/modules/perl/include
>> /path/to/httpd2/modules/perl/man
>>
>> This solution requires no extra logic during the build time, since we 
>> simply use the PREFIX MM argument. It also makes the mod_perl 
>> installed base self containing.
> 
> 
> sounds like a good idea.  however, I don't think I want this as the 
> default behavior.
> 
> in the "real" world :), there are probably very few people who are going 
> to want multiple mpms to choose from at the same time - you typically 
> will only roll out one in production (the one that you've proven works 
> for your application) and change it only after significant benchmarking, 
> research, and stresses.

I think we are going to encounter lots of cases where Unix folks will want to 
have both: prefork and worker, (and even perhaps perchild) installed on the 
same machine (not sure about production), so they can perform transition from 
pre-forked apps to threaded apps. And that's the situation I was talking about.

I suppose that this can be done as an addition to the Apache2 solution in the 
main perl tree.

__________________________________________________________________
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: rfc: allowing more than one mod_perl install - s/Apache2.pm/PREFIX+blib/

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Tue, 15 Apr 2003, Geoffrey Young wrote:

> Stas Bekman wrote:
[ .. ] 
> > The proposed solution:
> > 
> > Ditch the Apache2 coexistance workaround altogether and
> > install each mod_perl into its own PREFIX, preferabbly
> > outside the main perl tree.  Suggested default is
> > /path/to/httpd2/modules/perl, so we have:
> > 
> > /path/to/httpd2/modules/perl/lib
> > /path/to/httpd2/modules/perl/bin
> > /path/to/httpd2/modules/perl/include
> > /path/to/httpd2/modules/perl/man
> > 
> > This solution requires no extra logic during the build time,
> > since we simply use the PREFIX MM argument. It also makes the
> > mod_perl installed base self containing.
> 
> sounds like a good idea.  however, I don't think I want this as
> the default behavior.
[ .. ]

I'd tend to agree with Geoff, for the reasons he gave - it would
be a great option to have, but perhaps not as the default ...
With the option, though, would a user be able to override
the set PREFIX, in case of insufficient privileges?

Another aspect is Win32 - in this case permissions aren't the
issue, but ppm binary distributions might be (and perhaps also
might be for rpms). PPM installs things to the user's Perl tree,
so no strong assumptions about PREFIX could be hardcoded in the
mod_perl tree, as the PPM installation would effectively ignore
what PREFIX was when the package was built.

-- 
best regards,
randy


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: rfc: allowing more than one mod_perl install - s/Apache2.pm/PREFIX+blib/

[Geoffrey Young <ge...@modperlcookbook.org>]

> The proposed solution:
> 
> Ditch the Apache2 coexistance workaround altogether and install each 
> mod_perl into its own PREFIX, preferabbly outside the main perl tree. 
> Suggested default is /path/to/httpd2/modules/perl, so we have:
> 
> /path/to/httpd2/modules/perl/lib
> /path/to/httpd2/modules/perl/bin
> /path/to/httpd2/modules/perl/include
> /path/to/httpd2/modules/perl/man
> 
> This solution requires no extra logic during the build time, since we 
> simply use the PREFIX MM argument. It also makes the mod_perl installed 
> base self containing.

sounds like a good idea.  however, I don't think I want this as the default 
behavior.

in the "real" world :), there are probably very few people who are going to 
want multiple mpms to choose from at the same time - you typically will only 
roll out one in production (the one that you've proven works for your 
application) and change it only after significant benchmarking, research, 
and stresses.

so, given this one installation, I'm not sure that for a stable production 
installation I want to see Perl modules outside of the standard Perl tree - 
that's where people supporting Perl expect to find modules they 'use'.

where multiple mpms become important is for development (and developers :). 
  in that situation, yes, it would be nice to have a standard, and 
installing everything local to the Apache 2 install (alongside the current 
mod_perl.so) is a good idea.

> 
> The only issue with 3rd party modules builds. They can use 
> -Mlib=$PREFIX/lib to reach the mod_perl perl tree and should install 
> themselves under the same tree (all they need is to reuse the same PREFIX).

this is one of the reasons I think the above proposal should not be the 
default - _requiring_ PREFIX for _every_ third party installation seems like 
a rather large burden, especially considering that it would be there to 
support only a small fraction of the actual installations.  if the standard 
Perl tree were the default, then you would only need PREFIX if you're in 
your sandbox where you're playing with multiple mpms.

--Geoff





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org