> I *want* modperl to succeed. I *want* modperl2 to succeed. good :)
> 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 libraries. > > 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 > mainstream. 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. great! 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@perl.org 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
