Pratik wrote:
I don't think this problem can be fixed. That means that if someone mixes
and matches PerlSetEnv (or PerlPassEnv) in httpd.conf and %ENV of the same
key in PerlRequire, PerlConfigRequire, PerlPostConfigRequire and
sections. Whatever was the last value of that key before or
was enco
> I don't think this problem can be fixed. That means that if someone mixes
> and matches PerlSetEnv (or PerlPassEnv) in httpd.conf and %ENV of the same
> key in PerlRequire, PerlConfigRequire, PerlPostConfigRequire and
> sections. Whatever was the last value of that key before or
> was encounte
Stas Bekman said:
> The thing is: 99.9% of users need to have only one modperl generation,
> therefore I think the conflicting marking is the preferrable approach. But
> I could be wrong.
I'm not sure they actually mark them as conflicting, but they do seem to
be coping with this so far, since Red
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> =item * Distributors
>
> Distributors should mark the different generations of mod_perl as
> conflicting, so only one version can be installed using the binary
> package. Users requiring more than one installation should do a manual
> install.
+1
Adam Kennedy wrote:
=item * Distributors
Distributors should mark the different generations of mod_perl as
conflicting, so only one version can be installed using the binary
package. Users requiring more than one installation should do a manual
install.
>>> So I presume this would apply to all of A
Stas Bekman wrote:
Mind to post this to the list? It's an important issue, that was just an
idea I wrote last night.
Adam Kennedy wrote:
(off-list)
So I presume this would apply to all of Apache-related CPAN modules as
well?
Wouldn't this mean that people like debian are going to have
libapache
Stas Bekman wrote:
Pratik wrote:
Yup. The patch is working nice and solving all the issues related to
PerlPassEnv & PerlSetEnv.
I wrote a more extensive test and there are lots of problems with this
patch. The first is that %ENV values weren't making back into PerlSetEnv
table. I've fixed that (
David Wheeler wrote:
On Dec 29, 2004, at 6:49 PM, Geoffrey Young wrote:
for a bit of history here, what happens with mp2 is that if it sees a mp1
installation it installs everything under site_lib/Apache2/ (like
Apache::Filter becomes Apache2/Apache/Filter.pm) as to not collide with
existing module
Perrin Harkins wrote:
Adam Kennedy said:
While I'm thinking about it, has anyone talked to Red Hat or the Debian
people to see how the separate distribution of identically named module
will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they j
Perrin Harkins wrote:
Adam Kennedy said:
While I'm thinking about it, has anyone talked to Red Hat or the Debian
people to see how the separate distribution of identically named module
will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they
Adam Kennedy wrote:
If a module has XS code and doesn't provide a CLONE function, most
likely it is not thread-safe (you can grep for CLONE). Of course those
that provide the CLONE function aren't necessarily completely
thread-safe. e.g. I've added CLONE only for the top level class in
GTop, th
Adam Kennedy said:
> While I'm thinking about it, has anyone talked to Red Hat or the Debian
> people to see how the separate distribution of identically named module
> will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they just ship the mod
On Dec 29, 2004, at 6:49 PM, Geoffrey Young wrote:
for a bit of history here, what happens with mp2 is that if it sees a
mp1
installation it installs everything under site_lib/Apache2/ (like
Apache::Filter becomes Apache2/Apache/Filter.pm) as to not collide with
existing modules in the mp1 namespa
If a module has XS code and doesn't provide a CLONE function, most
likely it is not thread-safe (you can grep for CLONE). Of course those
that provide the CLONE function aren't necessarily completely
thread-safe. e.g. I've added CLONE only for the top level class in GTop,
the rest of classes in
Perrin Harkins wrote:
Adam Kennedy said:
I'm wondering how you plan to make the modifications to the various
modules that might be effected by this new concept of "two different
modules (APIs) with the same name"
Adam, this is under heavy discussion right now and is not really resolved.
There is
Adam Kennedy said:
> I'm wondering how you plan to make the modifications to the various
> modules that might be effected by this new concept of "two different
> modules (APIs) with the same name"
Adam, this is under heavy discussion right now and is not really resolved.
There is no solution that
Pratik wrote:
Yup. The patch is working nice and solving all the issues related to
PerlPassEnv & PerlSetEnv.
I wrote a more extensive test and there are lots of problems with this
patch. The first is that %ENV values weren't making back into PerlSetEnv
table. I've fixed that (and revamped things
Hi guys
I'm just reading through the docs of the new mod_perl and I had a couple
of questions. (and maybe issues).
Perl/CPAN Tool Chain
I'm just finishing up PPI.pm at the moment on a Perl Foundation grant,
and I know a lot of perl tool chain modules (autodocumentation,
depende
Ken Williams wrote:
On Dec 29, 2004, at 8:35 PM, Stas Bekman wrote:
Ken Williams wrote:
On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
with MM we override MY::constants so things end up in Apache2/
subdirs in blib/. That's about it. so if normally a file would be
installed under /foo/bar it'll b
On Dec 29, 2004, at 8:35 PM, Stas Bekman wrote:
Ken Williams wrote:
On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
with MM we override MY::constants so things end up in Apache2/
subdirs in blib/. That's about it. so if normally a file would be
installed under /foo/bar it'll be now installed unde
hi ken :) many belated congrats on your new addition :)
Ken Williams wrote:
>
> On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
>
>> with MM we override MY::constants so things end up in Apache2/ subdirs
>> in blib/. That's about it. so if normally a file would be installed
>> under /foo/bar i
Stas Bekman wrote:
Ken Williams wrote:
Um, doesn't that really break things (like, say, perl) that are
looking for modules in @INC and not map( "$_/Apache2", @INC)?
Break what things? Any perl program that wants to find mp2 modules
starts with 'use Apache2' or -MApache2.
What Stas means is that t
Ken Williams wrote:
On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
with MM we override MY::constants so things end up in Apache2/ subdirs
in blib/. That's about it. so if normally a file would be installed
under /foo/bar it'll be now installed under /foo/bar/Apache2.
Um, doesn't that really bre
On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
with MM we override MY::constants so things end up in Apache2/ subdirs
in blib/. That's about it. so if normally a file would be installed
under /foo/bar it'll be now installed under /foo/bar/Apache2.
Um, doesn't that really break things (like, say,
Ken Williams wrote:
On Dec 29, 2004, at 2:12 PM, Stas Bekman wrote:
But M::B doesn't support XS yet, so that's moot.
M::B has supported XS since it was in diapers.
Well, I've never used M::B, someone (?) said that it doesn't. If it does
then great.
so David and I were only talking about ModPerl:
On Dec 29, 2004, at 2:12 PM, Stas Bekman wrote:
But M::B doesn't support XS yet, so that's moot.
M::B has supported XS since it was in diapers.
so David and I were only talking about ModPerl::MB subclass of M::B
which will do the usual thing as any another non-mp2 module does, but
will subclass w
> In which case I've lost you, since ModPerl::MM doesn't call
> Apache::src->new->inc. I guess, you've meant:
>
> http://perl.apache.org/docs/2.0/api/ModPerl/MM.html#C_INC_
>
> is that right?
yes.
/me sighs
all I was doing was showing how things worked in mp1 and, thus, what mp2
does _equival
Geoffrey Young wrote:
note that even without the win32 foo mp1 still needs the call to
Apache::src->new->inc to find the proper header files.
wo, wo, wo, nobody was even suggesting to do that for mp1. mp2 was the
only one.
eesh... I wasn't suggesting that. I was just showing what ModPerl::MM doe
>> note that even without the win32 foo mp1 still needs the call to
>> Apache::src->new->inc to find the proper header files.
>
>
> wo, wo, wo, nobody was even suggesting to do that for mp1. mp2 was the
> only one.
eesh... I wasn't suggesting that. I was just showing what ModPerl::MM does
behi
Geoffrey Young wrote:
From what I understand, the whole
point of that module is to detect when both mod_perl1 and mod_perl2 are
installed, and, when they are, to add "Apache" to the install path
before installing mod_perl2-specific modules.
That's Apache2/ (not Apache).
well, that's not the _whole_
> From what I understand, the whole
> point of that module is to detect when both mod_perl1 and mod_perl2 are
> installed, and, when they are, to add "Apache" to the install path
> before installing mod_perl2-specific modules.
well, that's not the _whole_ point :) a mp1 Makefile.PL that needs to
Hi All,
So I've been talking to the mod_perl developers about providing
installation tools built on top of Module::Build. Specifically, they
have a module, ModPerl::MM, that can be used by CPAN modules built on
top of mod_perl to build themselves. From what I understand, the whole
point of that
32 matches
Mail list logo
