margol at beamartyr
Dec 28, 2004, 8:11 AM
Post #5 of 12
I personally side with Stas' intentions (if I understand them correctly) on
Re: About putting the blame on other shoulders
[In reply to]
the matter - it makes it easy for developers to work with both versions of
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
----- Original Message -----
From: "Stas Bekman" <stas [at] stason>
To: "Andreas J Koenig" <andreas.koenig.gmwojprw [at] franz>
Cc: "David Wheeler" <david [at] kineticode>; <advocacy [at] perl>;
"mod_perl Mailing List" <modperl [at] perl>; "Randal L. Schwartz"
<merlyn [at] stonehenge>
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 <stas [at] stason>
>> >> 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:stas [at] stason http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
> To unsubscribe, e-mail: advocacy-unsubscribe [at] perl
> For additional commands, e-mail: advocacy-help [at] perl
To unsubscribe, e-mail: advocacy-unsubscribe [at] perl
For additional commands, e-mail: advocacy-help [at] perl