I really don't see what the loaded guns are about - each side here deserves *lot* of credit for pointing out a big problem.
On the one hand, if people don't want to budge, and are saying it makes too much of a mess to continue trying to work around Stas' propsed "use Apache2" and suite of "MP::" installation tools, perhaps it's not unreasonable to simply force mp2 users to set up a seperate Perl installation? After all, users must set up seperate Apache distributions for mp 1 and 2. When you think about it, it's really a 2 way relationship: you're "importing the Apache API into Perl", as much as you're "embedding the Perl interpreter into Apache". Just like you can't use one Apache/mod_perl with two installations of Perl (say 5.6 and 5.8 on mod_perl1), it's fair to demand that you shouldn't use two versions of Apache/mod_perl (1.3/2.x) with one version of Perl. Chances are that a majority of people with mod_perl1/2 on the same machine are developers, and porting things over (or maintaining modules for both, or something else which is intelligent) - they'll all know how to install both in parallell "the hard way" (eg, setting up 2 perl installations); the majority of the non-developers are likely poor sysadmins who don't quite understand what they're getting themselves into with parallel installations, and we possibly shouldn't be giving them a trivial way to do it.
However, instead of "the opposition" making your collective point (And you DO have a good point), maybe you should take Stas' advice and actually think about the bigger problem: mod_perl is an embedded interpreter; ANY embedded Perl interpreter might have to deal with similar difficulties invovled with sharing modules. For example, what if I had multiple applications that all used an embedded interpreter - and each of those embedded interpreters needed a different version of the same Perl module(s).
By fighting down Stas now, you're potentially closing the door to other applications which deal with an embedded Perl interpreter, since they may not be able to coexist with other such applications (or even with the "normal" Perl interpreter), since there's only one "site" directory, which any application linked to the Perl shared object MUST share, and you can only have one version of any module installed at any given point.
Maybe I'm completly misunderstanding why Stas put all the effort into his framework to support; maybe my objections make no sense. But in any case, please STOP ARGUING - you're making a public spectacle that's gonna bash Perl in general as much as mod_perl specifically Many of you sound like offended six year olds, and it's going to become embarassing. One of the big points of Perl is TMTOWTDI - there isn't supposed to be "one way to do it", and just because everyone (myself included) is being lazy and not setting up dual Perl installations, since Stas was nice enough to provide a rudimentary workaround for it, you can't expect Stas's workaround to be "perfect" - he's got enough to deal with with mod_perl development without having to deal with how to fix Perl/CPAN's inability to support installation of multiple versions of modules.
Anyway, the fact is that this *does* seem to be a pretty heated flame war, so I'll shut up now before I get myself into more trouble than I already have.
Issac
----- Original Message ----- From: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Andreas J Koenig" <[EMAIL PROTECTED]>
Cc: "David Wheeler" <[EMAIL PROTECTED]>; <advocacy@perl.apache.org>; "mod_perl Mailing List" <modperl@perl.apache.org>; "Randal L. Schwartz" <merlyn@stonehenge.com>
Sent: Tuesday, December 28, 2004 5:01 PM
Subject: Re: About putting the blame on other shoulders
Andreas J Koenig wrote: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, what exactly do you call untruth? My attempt to make PAUSE/CPAN better and accomodate the growing community needs? Why is that untruth?
It's not a danger that people will believe me, it's a hope. If enough people believe in that may be things will change. Things shouldn't be cast in stone and they should evolve as the world evolve.
I truly don't understand why you refuse to believe that CPAN/PAUSE needs to grow.
Re: About putting the blame on other shoulders
It's not putting blame on other shoulders. It's an attempt to actually solve things. You know very well, that I didn't just say it's PAUSE/CPAN problem. I've spent hours trying to find a solution. I've even found a person who have agreed to implement the required changes. And all you can say: "put the blame on other shoulders"? thanks so much for giving me so much credit.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
