geoff at modperlcookbook
Dec 27, 2004, 7:36 AM
Post #6 of 13
> I *want* modperl to succeed. I *want* modperl2 to succeed.
Re: Slashdot | Help Test mod_perl 2 Release Candidates
[In reply to]
> I believe
> Stas has made two significant errors in this process, however:
> 1) expecting people to not have modperl1 for a significant time
> following the modperl2 release, like everyone would "upgrade
> tomorrow" thus trivializing the overlap issue.
actually, I don't see that at all. the way it works now is that if mp2 sees
a mp1 install it will install itself into Apache2/ to avoid confrontation.
the result is that mp1 will continue to function in normal perl terms - the
CPAN shell will do the right thing for mp1 modules (at least insofar as it
used to), perldoc will work correctly, etc.
so, in installing mp2 over mp1 the mp2 install should be invisible unless
you take explicit steps to make it otherwise. if this isn't the case then
it's an issue that should be immediately addressed, since that has been our
goal since the start. mp1 should continue without interruption.
the only kink here would be third-party CPAN modules for only mp2 - those
are _required_ to use ModPerl::MM::WriteMakefile (which knows to install
into Apache2/ if that's where mp2 was installed) instead of
ExtUtils::MakeMaker::WriteMakefile. while I've tried to do my best here
with a bunch of modules and perl.com articles, perhaps this point hasn't
been clear enough to the masses and that should be addressed.
> 2) expecting every step of the Perl distribution network to
> accommodate the hacky "use Apache2" solution instead of working on
> a more compatible solution. This means the CPAN indexer, the
> CPAN/CPANP installation tools, the "perldoc" command, and manpage
> installation (and others that I'm probably forgetting) which
> presume that Perl's installation @INC won't be magically mangled.
I don't think we expect CPAN to grok Apache2, just the local filesystem and
@INC. but you're right, the entire perldoc/CPAN/@INC thing is a real issue.
however, it's not as simple as renaming everything Apache2::*. why? it
just doesn't scale well. for example, there are _already_ compat issues
between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would
need Apache2::* for modules that use the Apache 2.0 API and Apache2.2::* for
those that use the 2.2 API. then perhaps Apache3::* someday, etc...
so, it's a more complex issue than people give it credit for. and
(unfortunately) mod_perl isn't the only one that suffers from it - stas has
mentioned GD and I was recently troubled by SQLite, but I'm sure that there
are other namespaces out there who struggle with versioning and external
> I was not made aware of *either* of these errors until recently. So,
> maybe my ranting seems a bit "day late and dollar short",
indeed. but we're here working it out instead of going off in a huff, which
is the way it should be. kudos to all :)
> but these
> mistakes are both critical to modperl2's acceptance into the
well, perhaps. I can see how it would really affect users who rely heavily
on the CPAN shell and perldoc, but I don't think it's as much of an issue
for people used to using wget and the online docs. so, in other words, it
probably affects the casual user more than the dedicated mod_perl
application developer. but that's just my suspicion. in either case,
something should be done to make things right.
> I would love to help. Tell me how. So far, the only thing I can see
> to do is to report these mistakes so that they can be discussed. I've
> seen reasonable support for my position... in fact, the only strong
> opposition appears to be Stas! And this is perfectly understandable.
> Stas has invested himself in an unworkable path. It'll take some work
> to sort it out. I'm willing to help with that.
what I think really needs to happen is that there should be a common way for
all things perl to deal with this issue - one that scales easily to many,
many versions and that common perl tools understand. if one is developed
mod_perl would certainly follow it. cpan-discuss [at] perl is where this
specific issue seems to come and go, so perhaps that is the best place to
sort it all out.
but until there is a universal solution, it's difficult for us mod_perl dev
people to "do the right thing" when no such thing exists. but let's work it
out together, which I'm sure we can.
To unsubscribe, e-mail: advocacy-unsubscribe [at] perl
For additional commands, e-mail: advocacy-help [at] perl