Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
>>>>> On Tue, 25 Dec 2007 10:47:48 -0800, "Philippe M. Chiasson" <[EMAIL >>>>> PROTECTED]> said: > Andreas J. Koenig wrote: >>>>>>> On Mon, 24 Dec 2007 15:07:20 -0800, "Philippe M. Chiasson" <[EMAIL >>>>>>> PROTECTED]> said: >> >> >> I then changed directory to apache.../src/modules/perl/ and did a >> >> 'make libperl.a', which did compile one for me. Then I switched back >> >> to mod_perl directory and retried a 'make' and indeed this finished >> >> without error. >> >> > Most likely caused by not having done >> >> > $> make clean >> >> > before trying again. When not doing that, src/modules/perl under >> > apache/src >> > will not be correctly re-generated. >> >> Nope, it's really some fight between Linux and Cygwin for the right of >> way. > Are you building this on Windows/Cygwin then ? No, I'm building on Linux. The thing that seems to have broken the linux gears is related to a patch that turns "so" into "dll" for cygwin but at the same time conflicts with linux' use of the LIBEXT macro which establishes a dependency on libperl.a. Your second attempt then removed the conflict but at the same time removed the dependency on the libperl.a completely. So then I had a libperl.a rule that was never invoked because the dependency was gone. My last patch "fixes" that for linux but makes no sense to you:-( >> I can make it work with this one line change but I don't know how >> much of your expectations are undermined by it: >> >> --- apaci/Makefile.tmpl~2007-12-25 05:28:23.448665692 +0100 >> +++ apaci/Makefile.tmpl 2007-12-25 05:28:36.567058818 +0100 >> @@ -37,7 +37,7 @@ >> ## >> >> # the library to build >> -MP_LIB=libperl.$(MP_LIBEXT) >> +MP_LIB=libperl.$(LIBEXT) >> >> # the objects to use >> MP_OBJS=\ >> >> >> Makes any sense? > Not much sense, no... > In your case, what does MP_LIBEXT end up being ? >From what I can see in the code it can only be "so" but I wonder why I do not see it expanded in any file. In my apache directory I grep recursively: # grep -r MP_LIBEXT . ./src/modules/perl/Makefile.tmpl:libperl.$(MP_LIBEXT): $(MP_OBJS_PIC) ./src/modules/perl/Makefile.tmpl: $(APXS) -i -a -n perl libperl.$(MP_LIBEXT) ./src/modules/perl/configure:echo "MP_LIBEXT=$my_soext" >>$my_makefileconf ./src/modules/perl/Makefile:libperl.$(MP_LIBEXT): $(MP_OBJS_PIC) ./src/modules/perl/Makefile:$(APXS) -i -a -n perl libperl.$(MP_LIBEXT) I get the impression that src/modules/perl/configure is not being run for whatever reason. Let me know if I can try further things out. -- andreas
Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
> On Mon, 24 Dec 2007 15:07:20 -0800, "Philippe M. Chiasson" <[EMAIL > PROTECTED]> said: >> I then changed directory to apache.../src/modules/perl/ and did a >> 'make libperl.a', which did compile one for me. Then I switched back >> to mod_perl directory and retried a 'make' and indeed this finished >> without error. > Most likely caused by not having done > $> make clean > before trying again. When not doing that, src/modules/perl under apache/src > will not be correctly re-generated. Nope, it's really some fight between Linux and Cygwin for the right of way. I can make it work with this one line change but I don't know how much of your expectations are undermined by it: --- apaci/Makefile.tmpl~2007-12-25 05:28:23.448665692 +0100 +++ apaci/Makefile.tmpl 2007-12-25 05:28:36.567058818 +0100 @@ -37,7 +37,7 @@ ## # the library to build -MP_LIB=libperl.$(MP_LIBEXT) +MP_LIB=libperl.$(LIBEXT) # the objects to use MP_OBJS=\ Makes any sense? -- andreas
Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
> On Mon, 24 Dec 2007 13:12:05 -0800, "Philippe M. Chiasson" <[EMAIL > PROTECTED]> said: > Looks like it was caused by httpd's own stuff defining LIBEXT and clobbering > our own. Can you try the attached patch ? Maybe I'm too tired right now, but on the first try it did again not work, saying cc: modules/perl/libperl.a: No such file or directory make[3]: *** [target_static] Error 1 make[3]: Leaving directory `/home/src/apache_1.3.39/src' make[2]: *** [build-std] Error 2 make[2]: Leaving directory `/home/src/apache_1.3.39' make[1]: *** [build] Error 2 make[1]: Leaving directory `/home/src/apache_1.3.39' make: *** [apaci_httpd] Error 2 I then changed directory to apache.../src/modules/perl/ and did a 'make libperl.a', which did compile one for me. Then I switched back to mod_perl directory and retried a 'make' and indeed this finished without error. I'll retry tomorrow if I did something stupid. Let me know if this rings a bell for you. Good night, -- andreas
Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
> On Sun, 23 Dec 2007 14:35:51 -0800, "Philippe M. Chiasson" <[EMAIL > PROTECTED]> said: > Oh, are you trying to build mod_perl statically ? Yes, I've always built it statically. I thought that is the default on linux. >>> On Fri, 21 Dec 2007 23:36:53 -0800, "Philippe M. Chiasson" <[EMAIL >>> PROTECTED]> said: > Yes, but I'd like to try reproducing this myself. > Can you tell me: > $> perl -V:config_args config_args='-Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Dprefix=/usr/local/perl-5.10.0 -Duse64bitint' The usedevel bit has no significance for stable/released perls, I just have it always there. > As well as the version of httpd you are trying against, as well as how > it was built/configured. 1.3.39 with BenSSL (apache_1.3.37+ssl_1.57.tar.gz). I did not configure anything myself and let it be built by mod_perl. The BenSSL part is just an extra hurdle that you can avoid for sure. > Same thing for mod_perl. - EVERYTHING=1 - USE_APACI=1 - APACHE_PREFIX=/usr/local/apache-1.3.39 - APACI_ARGS=--enable-module=info,--enable-module=status - APACHE_SRC=/home/src/apache_1.3.39/src - APACHE_SRC_DEFAULT=/home/src/apache_1.3.39/src - DO_HTTPD=1 > Getting the exact argument you used to build/configure these might allow > me to reproduce, and hopefully, to fix as well. Let me know if you need more or if you need a login. -- andreas
Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
>>>>> On Sat, 22 Dec 2007 13:52:26 +0100, [EMAIL PROTECTED] (Andreas J. Koenig) >>>>> said: >>>>> On Fri, 21 Dec 2007 23:36:53 -0800, "Philippe M. Chiasson" <[EMAIL >>>>> PROTECTED]> said: >> http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz > The apache Configure on my box sets my LIBEXT to "a" which is indeed > what I always wanted to have. So the rules for "so" were correct as > they were written and I do not know if they ever were invoked. The > result of the 1.31 build is that the httpsd in the end is only 0.5 MB > instead of 1.7 MB and it doesn't start either. Sorry, I forgot this interesting make error message: Makefile:141: warning: overriding commands for target `libperl.a' Makefile:136: warning: ignoring old commands for target `libperl.a' This is the content of the Makefile (maybe something is off by one, but the point is that LIBEXT=a leads to a duplicate rule and the wrong rule wins. 135 libperl.a: $(MP_OBJS) 136 $(MP_RM) $@ 137 $(MP_AR) crv $@ $(MP_OBJS) 138 $(MP_RANLIB) $@ 139 140 libperl.$(LIBEXT): $(MP_OBJS_PIC) 141 $(MP_RM) $@ 142 $(MP_LD) $(MP_LDFLAGS_SHLIB) -o $@ $(MP_OBJS_PIC) $(MP_LIBS) 143 -- andreas
Re: RELEASE CANDIDATE] mod_perl-1.31 RC1
> On Fri, 21 Dec 2007 23:36:53 -0800, "Philippe M. Chiasson" <[EMAIL > PROTECTED]> said: > http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz Wow, what a fast release, thanks! But sorry, nope, it doesn't work on my linux box. The apache Configure on my box sets my LIBEXT to "a" which is indeed what I always wanted to have. So the rules for "so" were correct as they were written and I do not know if they ever were invoked. The result of the 1.31 build is that the httpsd in the end is only 0.5 MB instead of 1.7 MB and it doesn't start either. I'm unable to tell what exactly needs fixing. Does my description help? -- andreas
Re: Perl 5.10
>>>>> On Thu, 20 Dec 2007 11:38:02 -0500, Colin Wetherbee <[EMAIL PROTECTED]> >>>>> said: > Have any of you used mod_perl with Perl 5.10 yet? Are there any > gotchas to consider? Modperl1 doesn't work, patch available. As for modperl2 I don't know. I'm resending my posting which probably got lost in a moderator queue or what (I just re-subscribed, so this one should probasbly come through): From: [EMAIL PROTECTED] (Andreas J. Koenig) Subject: perl 5.10 will not work with modperl 1.30, please consider new release To: modperl@perl.apache.org Date: Fri, 14 Dec 2007 08:28:14 +0100 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00278.html This is the currently latest posting in the thread that worked out the relevant issue. Would be really cool if mod_perl1 could be brought up to date so that people working with 5.10 do not have to hunt for patches. I fear I do not understand enough of mod_perl to volunteer to make a release. Thanks, -- andreas
Re: how to use mod_perl sections with mod_jk?
>>>>> On Wed, 2 Aug 2006 14:16:00 -0500, [EMAIL PROTECTED] said:
> Can you show me how this can be configured then without using $PerlConfig
> JkWorkerProperty worker.list=myWorker
> JkWorkerProperty worker.myWorker.port=$workerPort
> JkWorkerProperty worker.myWorker.host=127.0.0.1
> JkWorkerProperty worker.myWorker.type=ajp13
> JkWorkerProperty worker.myWorker.secret=secretword
I think such things can _only_ be done with $PerlConfig. That's why I
use it everywhere. I only have to write things as documented in the
apache docs and need not understand the subtleties of the other
variables supported by Apache*::PerlSections
> If I try
> push @JkWorkerProperty, "worker.list=myWorker";
> it doesn't setup right.
Not surprising for me.
> This is rather unique because it's valid apache syntax but not that common
I cannot understand your sentence because I see no valid apache syntax here.
> I'm now using $PerlConfig to work around this but I'd like to know if there
> was another way.
> This is how I'm
>
> my $logDir = $ENV{'X_LOGDIR'};
> my $workerPort = $ENV{'X_WORKER_PORT'};
> $PerlConfig .=< JkWorkerProperty worker.list=myWorker
> JkWorkerProperty worker.myWorker.port=$workerPort
> JkWorkerProperty worker.myWorker.host=127.0.0.1
> JkWorkerProperty worker.myWorker.type=ajp13
> JkWorkerProperty worker.myWorker.secret=secretword
> JkLogFile $logDir/mod_jk.log
> JkLogLevel debug
> JkShmFile $logDir/jk-runtime-status
> END
> Please note in order to do the $ENV above I have to have this.
>
> # repopulate %ENV
> for (`env`) {
> next unless /^X_/;
> /(.*)=(.*)/;
> $ENV{$1} = $2;
> push @PassEnv, $1;
> #print "$_\n";
> }
> this essentially puts back what mod_perl took out of %ENV upon startup and
it
> seems to remain in %ENV across all Perl Sections. I have not seen any
example
> where PassEnv can be used instead of the above approach.
> ---
>
http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl
>
http://perl.apache.org/docs/1.0/guide/porting.html#Passing_ENV_variables_to_CGI
> "The Perl %ENV is cleared during startup, but the C environment is left
intact.
> With a combo of forking `env` and sections you can do even do
wildcards
> matching. For example, this passes all environment variables that begin with
> the letter H:"
> ---
> What is the correct way to define a variable that can hold state that will
> survive across Perl Sections but yet won't end up in the httpd
configuration?
> Do I have to declare a my and use $ENV everytime I need to refer to these
> variables in a Perl Section?
If the Perl section are in the same file, I'd use lexical variables
because they are ignored by the mod_perl mechanism. If they are in
different files, pick names that are unlikely to be interpreted by
perl or mod_perl. Maybe use underscores or so. Definitely no need to
use %ENV, $robert_at_elastica::foo::bar works as well and doesn't
trigger perl's environment handling.
> Unfortunately with the mod_perl setup I'm using I cannot use
> Apache::PerlSections->dump so it's hard to verify things.
> Quoting Robert Nicholson <[EMAIL PROTECTED]>:
>> So can you or somebody else post a complete httpd.conf that makes use
>> of $PerlConfig then?
>>
>> On Aug 1, 2006, at 2:24 PM, Andreas J. Koenig wrote:
>>
>> >>>>>> On Tue, 1 Aug 2006 13:56:31 -0500, [EMAIL PROTECTED] said:
>> >
>> >> That resulted in errors at least in my case.
>> >
>> > You did read that I said you need SVN recent for apache2?
>> >
>> > --
>> > andreas
>>
>
> This message was sent using IMP, the Internet Messaging Program.
--
andreas
Re: how to use mod_perl sections with mod_jk?
> On Tue, 1 Aug 2006 13:56:31 -0500, [EMAIL PROTECTED] said: > That resulted in errors at least in my case. You did read that I said you need SVN recent for apache2? -- andreas
Re: how to use mod_perl sections with mod_jk?
> On Tue, 1 Aug 2006 11:06:15 -0500, [EMAIL PROTECTED] said: > Just exactly how does $PerlConfig work? > Can I put my entire configuration in a here document using $PerlConfig? Yes. > What are the limitations with $PerlConfig? Try it out. The Apache::PerlSections manpage is a bit terse. But in Apache2 it's better: http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.html As I said, it is like an Include statement on a scalar. $PerlConfig = "Alias /foo /bar\n"; It's that easy. -- andreas
Re: how to use mod_perl sections with mod_jk?
> On Mon, 31 Jul 2006 23:00:33 -0500, Robert Nicholson <[EMAIL PROTECTED]> > said: > So I'm trying to make a great deal of my httpd.conf dynamic based > primarily on hostname etc. > I have most of it working but I've found that at least in my case I > cannot use mod_jk directives in a perl section. > Q. Should I be able to use mod_jk directives in a perl section? > > push @JkWorkerProperty, [qw(worker.myWorker.port $workerPort)]; > > also I often want to do with Apache-> module() but how would I do say an Include where the > value was set in a perl stanza but the Include will be outside the > perl stanza. Failing that can I "Include" static httpd.conf > snippests in a perl section with say Apache-> include()? > Point is the path varies so I want to include where my variable has > scope. All this works if you use $PerlConfig instead of symbol table manipulations. $PerlConfig is like an include statement for a string. Works fine with apache1 but needs recent SVN for apache2. -- andreas
Re: $PerlConfig broken
> On Mon, 17 Jul 2006 13:04:58 -0700, "Philippe M. Chiasson" <[EMAIL
> PROTECTED]> said:
>> [Mon Jul 17 12:52:15 2006] [warn] The Alias directive in mod_perl at line 1
>> will probably never match because it overlaps an earlier Alias.
> The attached patch should address this problem. Let me know if it works and
> helps locating the source of that warning.
What the patch does get right is the filename where the error happens,
and this is already a great achievement -- Thanks much!
But sorry, no, it does not cut it for my tests: the line number
doesn't help me. Maybe there are examples where the line number
matches, but in my tests it didn't.
What we are usually doing is something like
for (){
$PerlConfig .= "Include \n"; # these files contain further Perl Sections
}
So for our special case we would need the line number of the string in
$PerlConfig. Others might use @PerlConfig and they would be interested
in the line number and the index of the element that has a problem.
--
andreas
Re: $PerlConfig broken
> On Mon, 10 Jul 2006 12:20:30 -0700, "Philippe M. Chiasson" <[EMAIL > PROTECTED]> said: >> ok, thanks for trying :) >> >> I'm including gozer here, since he is the main PerlConfig guy - I >> wouldn't want to step on his toes trying to implement a fix for this >> issue. but it we harp on him he will probably have an answer in a >> matter of seconds ;) > Slightly longer than a few seconds, but here is a patch that will probably > fix this issue as well as the the one linked to. Very nice, thanks very, very much, it seems to work perfectly well. One nit while we are at it: errors during execution of $PerlConfig would be much less pain if we could get real line numbers and file names. From the manpage I would believe that this is feasible now? Look what I got (the error was well spotted and correct, but I still did not know where to search because I have many sections and many $PerlConfig variables): [Mon Jul 17 12:52:15 2006] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlier Alias. -- andreas
Re: $PerlConfig broken
>>>>> On Sun, 09 Jul 2006 01:15:40 -0700, "Philip M. Gollucci" <[EMAIL
>>>>> PROTECTED]> said:
> Philip M. Gollucci wrote:
>> Andreas J. Koenig wrote:
>>> > http://marc2.theaimsgroup.com/?l=apache-modperl-dev&m=114021879222434&w=2
>> Since Geoff was previously involved, I'll let him handle this, but I'm +1
>> for the patch
>> as add_config() takes a scalar string not an array, so dump_special() as
>> writting is clearly wrong.
>>
>> The only thing I could thing of differently would be if you wanted instead
>> of the foreach()
>> $self->add_config(join('', @data))
>>
>> I've not traced what dump_special is supposed to be doing yet, so I don't
>> know which is correct.
>>
>>
> I take that back,
> do something like this instead:
>
> use Apache::Test ();
> if (Apache::Test::have_module('mod_alias.c')) {
> push @Alias, ['/perl_sections', '@DocumentRoot@'];
> $Location{'/perl_sections'} = {
> 'PerlInitHandler' => 'ModPerl::Test::add_config',
> 'AuthType' => 'Basic',
> 'AuthName' => 'PerlSection',
> 'PerlAuthenHandler' => 'TestHooks::authen_basic',
> };
> }
>
I'm not sure what you want to say. The above has not much to do with
my bugreport, at least on the surface. Are you suggesting I should not
use $PerlConfig and prefer the %Location/@Alias syntax? Then I must
say, I'm not a fan of these constructs, I *muchly* prefer $PerlConfig.
--
andreas
Re: $PerlConfig broken
> On Fri, 07 Jul 2006 08:44:37 -0400, Geoffrey Young <[EMAIL PROTECTED]> > said: >> This piece works: >> >> >> $PerlConfig = "Alias /ping/ /tmp/ping/\n"; >> >> >> >> >> >> But the following doesn't: >> >> >> $PerlConfig = "Alias /ping/ /tmp/ping/ >> >> >> "; >> >> > this patch seems to have stalled: > http://marc2.theaimsgroup.com/?l=apache-modperl-dev&m=114021879222434&w=2 > can you give it a whirl and see if it fixes things? Thanks! It doesn't fix the bug I reported. But it brings me closer to a workaround. It allows me to write the pretty weird looking config file: @PerlConfig = split /\n/, < EOC Before the patch I had no success with @PerlConfig, so apparently Frank's patch fixes @PerlConfig. For the bug I am reporting, there's something missing to split config lines into single directives. -- andreas
$PerlConfig broken
My installation is Debian based which has some apache 2.0.55-4 and some modperl 2.0.2-2. Let me know if you need further details. My configuration is nearly completely the default one and I have only one section which I keep in a separate file and which I "Include" from the default apache2.conf. This piece works: $PerlConfig = "Alias /ping/ /tmp/ping/\n"; But the following doesn't: $PerlConfig = "Alias /ping/ /tmp/ping/ "; The error message is: Starting apache 2.0 web server...Syntax error on line 2 of /services/mobile/framework/etc/httpd2.conf: $parms->add_config() has failed: Alias takes two arguments, a fakename and a realname at /usr/lib/perl5/Apache2/PerlSections.pm line 203.\n failed! and apache2 refuses to start. -- andreas
Re: putting config vars in httpd.conf
> On Thu, 27 Apr 2006 23:24:42 -0400, Jonathan Vanasco <[EMAIL PROTECTED]> > said: > I think i owe this list a keg or two by now. Although they haven't mentioned -D/define yet? -- andreas
howto streamline warnings
What is the recommended way to configure mod_perl's behaviour on warn()?
Is there a configurable connection between Apache::Log and
CORE::warn() or do I write a global $SIG{__WARN__}?
Background: we have already plenty of handlers that all usually use
perl's warn to write their diagnostics to error_log. We'd like to add
the timestamp of log_error to all these warnings an would like to do
it with a single line if possible.
Thanks in advance,
--
andreas
Re: go crazy with me
> On 20 Dec 2005 16:21:42 -0800, merlyn@stonehenge.com (Randal L. Schwartz) > said: > Are you already using a reverse-proxy? Make sure the front lightweight > servers *do* use cache and *don't* use keep-alive to the backend... > your heavy backend will spit the entire response, and go free to service > the next request... your thin front-end will then deliver that response > slowly as needed. I should not have mentioned that the customers are slow as well. Currently our main concern is that our processes have to wait for several data sources, then compute the answer and that our valuable memory is wasted during the wait. -- andreas
Re: Solving mod_perl scalability issues for lots of slow connections
> On Tue, 20 Dec 2005 14:42:12 -0800, Ken Simpson <[EMAIL PROTECTED]> said: > [note: Subject changed from "go crazy with me" -- LoL] >> I'd also like to hear what people are doing when the apache model has >> scaling problems. We have one problematic project here: we're a >> gateway and must server a high number of very slow customers to a high >> number of very slow feeds. Ideally we would run this in an event loop >> or in coroutines/continuations style, but we have not yet tried that >> out, mainly because so much of our infrastructure relies on everything >> being apache. Is there something in apache2 that would make our lives >> easier? (we have not yet switched to apache2 at all) > Hi Andreas, > I wonder if our asynchronous system could help. Possibly. I'm looking forward to the release and watching thisspace:) -- andreas
Re: go crazy with me
> On Tue, 20 Dec 2005 09:40:43 -0500, Matt Sergeant <[EMAIL PROTECTED]> > said: > I'm curious as to how you've mixed things up though - if the details > aren't private IP I'd love to know more. Me too:-) I'd also like to hear what people are doing when the apache model has scaling problems. We have one problematic project here: we're a gateway and must server a high number of very slow customers to a high number of very slow feeds. Ideally we would run this in an event loop or in coroutines/continuations style, but we have not yet tried that out, mainly because so much of our infrastructure relies on everything being apache. Is there something in apache2 that would make our lives easier? (we have not yet switched to apache2 at all) -- andreas
Re: Maintainer of Apache::DBI
> On Mon, 5 Dec 2005 16:52:30 +0100, "Frank Maas" <[EMAIL PROTECTED]> said: >> I don't think that Apache::DBI CPAN indexing problem is off topic, >> since I think that mod_perl community doesn't known it too much. >> >> So, I suggest you to repost also to modperl list. Thanks, I've fixed that on the CPAN indexer. It will take a few hours to propagate, of course. -- andreas
Re: About putting the blame on other shoulders
> On Tue, 28 Dec 2004 10:54:27 -0500, Stas Bekman <[EMAIL PROTECTED]> said: > Cure wrote: >> Everybody needs to "STEP BACK" and realize how much work and soul >> Stas has put into mod_perl. >> He deserves A LOT OF CREDIT. Keep up the Good work Stas. Actually, I love Stas. And I'm sure he knows that. > but we are talking about a different kind of credit here. Andreas has > put just as much work and soul if not more into PAUSE/CPAN. I was talking > about the credits of actually trying to resolve the current conflict, > rather than just trying to make someone else do the work. I was referring to the sentence. once PAUSE is fixed, and CPAN clients are adjusted, it will just work. This is what gives the reader the false impression that (1) only PAUSE and CPAN clients need to be fixed, that (2) there is an agreed-upon way of fixing it, and (3) somebody will do just that. All three claims are very unlikely to be true. -- andreas -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
About putting the blame on other shoulders
> On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman <[EMAIL PROTECTED]> said: >> Will it not also affect us who build mod_perl applications and want >> an easy-to-use installer to just work for people who download our >> software? Frankly, I don't think that it should be fine for just the >> dedicated mod_perl developer. This is one place where PHP is kicking >> the crap out of us. > us == perl, once PAUSE is fixed, and CPAN clients are adjusted, it will > just work. Stas, please stop propagating this fairy tale. The danger is, that people will believe you. This I call unfair propaganda as it tries to put the blame on somebody else's shoulders. That's not a very promising strategy to solve problems. Listen carefully: it is very unlikely that PAUSE and CPAN get fixed as you call it. There is no solution at hand and 4 people who you know well and who in turn know the problem domain very well have agreed and have told you so. So please stop telling untruth. -- andreas -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
