Re: Slashdot | Help Test mod_perl 2 Release Candidates
On Mon, Dec 27, 2004 at 12:10:47PM -0500, Perrin Harkins wrote: > > The real significant issue to address, IMO, has to do with CPAN's > > indexing of the Apache:: modules common to both mp1 and mp2 core > > distros, because those packages set the underlying apache[12] > > architecture. > > That's what I'm saying -- don't fix it. Tell people they need to keep two > perl installations if they want to run both. They will almost certainly > need to anyway if they intend to port modules from one to the other > without breaking the current working installation or renaming all of their > own modules. Has any one considered using only.pm? http://search.cpan.org/~ingy/only/ > I'm just not confident that things like PAUSE and CPAN.pm will change in a > timely fashion, and even if they did I don't see how that would help the > millions of mod_perl installations already out there. They don't all have to change. mp2 just needs to list a 'fixed' version of CPAN in it's dependencies... -J -- pgpexoQbbWkez.pgp Description: PGP signature
Re: [mp1] Linking confusion
On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote: > >During compilation of mod_perl, I was seeing undefined reference errors > >which are nicely described on the install page[1]. The prescription > >suggests rebuilding Perl with dynamic linking; apparently the version > >that's shipped with Debian is not dynamically linked(?). Sounds fine, > >but I'm not a C programmer so am not sure exactly what this means. > > Now that you know what does it take, please send a patch that extends [1] > to explain how to do that. I've started working on a patch for the install doc[1] but have come across a couple of questions that I'm sure someone on the list could answer for me. 1) The docs refer to building a "dynamically linked Perl." Shouldn't the Perl be lowercase since we're talking about the interpreter, not the language? 2) In the same sentence, it says that a dynamically linked perl will have a libperl.a. Isn't that a libperl.so? Could someone describe the differences between libperl.a and libperl.so? I see that it exists in the apache source directory which makes me think it is used when building modperl. If I'm building mp statically linked, I shouldn't need libperl.a after I've installed, right? Is this the library that has been more appropriately named modperl.a in MP2? Cheers! William [1] http://perl.apache.org/docs/1.0/guide/install.html#Undefined_reference_to__PL_perl_destruct_level_ -- Knowmad Services Inc. http://www.knowmad.com -- 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
Re: Slashdot | Help Test mod_perl 2 Release Candidates
Joshua Hoblitt wrote: On Mon, Dec 27, 2004 at 12:10:47PM -0500, Perrin Harkins wrote: The real significant issue to address, IMO, has to do with CPAN's indexing of the Apache:: modules common to both mp1 and mp2 core distros, because those packages set the underlying apache[12] architecture. That's what I'm saying -- don't fix it. Tell people they need to keep two perl installations if they want to run both. They will almost certainly need to anyway if they intend to port modules from one to the other without breaking the current working installation or renaming all of their own modules. Has any one considered using only.pm? http://search.cpan.org/~ingy/only/ Please read: http://perl.apache.org/docs/2.0/user/porting/porting.html#__pm__so__Files_Collision I'm just not confident that things like PAUSE and CPAN.pm will change in a timely fashion, and even if they did I don't see how that would help the millions of mod_perl installations already out there. They don't all have to change. mp2 just needs to list a 'fixed' version of CPAN in it's dependencies... I like your thinking Joshua :) -- __ Stas BekmanJAm_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 -- 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
Re: recommendations
Octavian Rasnita wrote: Hi, I want to configure a production server that uses mod_perl and I don't know what version to choose because I see that mod_perl 2 is not stable yet. What do you recommend, to install Apache 1.3 and mod_perl 1 and use it until mod_perl 2 will be stable enough, or do you think that mod_perl 2 can be enough stable in order to be used for other purposes than testing? The programs for the production server are not ready yet, and it will take some more months until I will need to install the production server. I'd say go with mp2.0. If it helps, 2.0.0 should be out in the next two weeks (we have about 3-4 remaining bugs to resolve). If you encounter problems we fix them almost as soon as you report them, so have no fear. -- __ Stas BekmanJAm_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 -- 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
Re: [mp1] Linking confusion
William McKee wrote: On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote: During compilation of mod_perl, I was seeing undefined reference errors which are nicely described on the install page[1]. The prescription suggests rebuilding Perl with dynamic linking; apparently the version that's shipped with Debian is not dynamically linked(?). Sounds fine, but I'm not a C programmer so am not sure exactly what this means. Now that you know what does it take, please send a patch that extends [1] to explain how to do that. I've started working on a patch for the install doc[1] but have come across a couple of questions that I'm sure someone on the list could answer for me. 1) The docs refer to building a "dynamically linked Perl." Shouldn't the Perl be lowercase since we're talking about the interpreter, not the language? +1 2) In the same sentence, it says that a dynamically linked perl will have a libperl.a. Isn't that a libperl.so? You are correct. Could someone describe the differences between libperl.a and libperl.so? libfoo.a is an archive used at linking time - it's completely included in the final application that linked it. libperl.so is a shared library. At the linking time the application only knows which library it wants. Only at the loading time (runtime) that library will be loaded. One of the benefits of using a shared library, is that only it's loaded by one application, any other application using the same library will not need load it, it'll be shared (a service provided by the kernel). In the case of static libfoo.a, it'll be loaded as many times as there are applications that included it, thus consuming more memory. Of course this is not the only benefit of using shared libs. I see that it exists in the apache source directory which makes me think it is used when building modperl. If I'm building mp statically linked, I shouldn't need libperl.a after I've installed, right? Is this the library that has been more appropriately named modperl.a in MP2? Yes, that's the result of the unfortunate naming scheme in Apache 1.3. So you have libperl.(so|a) which is perl, and you have libperl.(so|a) which is modperl. You are certainly looking at the modperl version of libperl.a if you find it in the apache directory. perl's libperl.(so|a) lives under something like 5.8.6/i686-linux/CORE/ And yes, mp2's lib is mod_perl.(so|a). [1] http://perl.apache.org/docs/1.0/guide/install.html#Undefined_reference_to__PL_perl_destruct_level_ -- __ Stas BekmanJAm_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 -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] -- Meanwhile I've found a solution proposed by Andreas 1.5 years ago, which might work as a better workaround from all the ones proposed so far: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00264.html -- Looks very promising to me. Is there a way to tell PAUSE to index mod_perl's Apache::* modules from a bundle? If so, that might provide a decent solution for both mod_perl and libapreq (and other Apache::* modules that find themselves in a similar situation). I'm not sure I understand what you ask, Joe. The indexer indexes anything that upload to PAUSE (as long as you have perms). So we need release mp1 with a new package: Bundle::mod_perl1::core which has the same version as mod_perl.pm and mp2 distro with: Bundle::mod_perl2.0::core which has the same version as mod_perl.pm Now other packages can create a dependency on those packages, instead of mod_perl.pm. The question is whether we should tell PAUSE to exclude any other packages from indexing. -- __ Stas BekmanJAm_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 -- 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
Re: [mp1] Linking confusion
Thanks for the clear explanation of *.a and *.so files, Stas. I'm starting to grok how it works together. I've attached the diff to the install docs to this message which incorporates some of your notes about .so and .a files. I found this information hard to find while browsing Google, Perlmonks and the modperl docs. I hope that you will include them in some form. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com --- /tmp/install.pod.orig 2004-12-31 10:04:39.0 -0500 +++ /tmp/install.pod.wlm2004-12-31 11:58:30.0 -0500 @@ -681,9 +681,38 @@ mod_perl.o(.text+0x13b): undefined reference to `Perl_av_undef' [more errors snipped] -This happens when you have Perl built statically linked, with no -shared I. Build a dynamically linked Perl (with -I) and the problem will disappear. +This happens when you have perl built statically linked, with no +shared I library. Build a dynamically linked perl (with +I) and the problem will disappear. See the "Building a shared Perl +library" section from the I file that comes with Perl sources. Also +see L<"Chapter 15.4 - Perl Build +Options"|http://modperlbook.org/html/ch15_04.html> from I. + +=head4 Further notes on libperl.(a|so) + +Library files such as I are archives that are used at linking time - +these files are completely included in the final application that linked it. + +I is a shared library. At the linking time the application only +knows which library it wants. Only at the loading time (runtime) that +library will be loaded. + +One of the benefits of using a shared library, is that it's loaded only once, +any application using the same library will not need load it, it'll be shared +(a service provided by the kernel). In the case of static I, it'll be +loaded as many times as there are applications that included it, thus consuming +more memory. Of course this is not the only benefit of using shared libs. + +In mod_perl1, the library file is unfortunately named libperl.(so|a). So you +have libperl.(so|a) which is perl, and you have libperl.(so|a) which is +modperl. You are certainly looking at the modperl version of libperl.a if you +find it in the apache directory. perl's libperl.(so|a) lives under something +like 5.8.6/i686-linux/CORE/. + +Some distributions (notably Debian) have chosen to put libperl.so into the +library path (e.g., /usr/lib) which will cause linking problems when compiling +mod_perl. You should delete or move aside the libperl.so while building +mod_perl or else will likely encounter further errors. =head2 mod_perl Building (make) -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: [...] >> Looks very promising to me. Is there a way to tell PAUSE to index >> mod_perl's Apache::* modules from a bundle? If so, that might >> provide a decent solution for both mod_perl and libapreq >> (and other Apache::* modules that find themselves in a similar situation). > > I'm not sure I understand what you ask, Joe. The indexer indexes > anything that upload to PAUSE (as long as you have perms). > > So we need release mp1 with a new package: > >Bundle::mod_perl1::core > > which has the same version as mod_perl.pm > > and mp2 distro with: > >Bundle::mod_perl2.0::core > > which has the same version as mod_perl.pm > > Now other packages can create a dependency on those packages, instead of > mod_perl.pm. If you're going that route, I really see that as being worse than introducing a new mod_perl2 package with mp2 and restoring all of mp1's CPAN indexing (including mod_perl.pm). I now think was a mistake for any of the Apache::* core modules to be indexed with mp1, because it looks like a wedding between the Apache:: APIs and the mp1 implementation of them. This is, IMO, the kernel of the complaints against the mp2 release plan. -- Joe Schaefer -- 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
Re: apache:session and mod perl
I know what's happening now, it dawned on me after I wrote this last night. A deadlock happens when you have an updater that acquires a write lock, but it's waiting for the first updater that is also in a SELECT FOR UPDATE but has not yet acquired a write lock. The first updater can't finish because it can't acquire a write lock that the second updater has already obtained, and the second updater can't update until the first one finishes, which it can't. Which also explains why Apache::Session::Flex doesn't list File as one of the supported Lock options. A workable hack would probably be to have Apache::Session::Lock::File always set Transaction to 1 if the backend store was postgres. Chris On Thu, 30 Dec 2004 23:41:16 -0800, Chris Ochs <[EMAIL PROTECTED]> wrote: > > > I tried setting Lock to File instead of Null, but there is some sort > > > of contention issue because after the first request all other requests > > > hang like they are waiting for a lock to be release. > > > > This usually means you have a scoping bug in your code. If the session > > object never goes out of scope, it will not release the lock. > > I put some loggin into apache::session::lock::file, and then switched > between using apache::session::file and apache::session::flex with > postgres and Lock set to File. > With postgres it calls acquire_read lock a bunch of times in a row > with an acquire_write_lock thrown in and then something blocks. Using > apache::session::file it alternates correctly and doesn't do that. > There has to be some logic in apache::session that is different than > apache::session::file. > > Here is a log when using apache::session::file. I put the pid in front. > > 96836 acquire_read_lock > 96836 acquire_write_lock > 96836 release_all_lock > 96836 DESTROY > 96836 release_all_lock > 96822 acquire_read_lock > 96822 acquire_write_lock > 96822 release_all_lock > 96822 DESTROY > 96822 release_all_lock > 96836 acquire_read_lock > 96836 acquire_write_lock > 96836 release_all_lock > 96836 DESTROY > 96836 release_all_lock > > Here is a log using flex with postgres and Lock set to File. > 96824 acquire_read_lock > 96834 acquire_read_lock > 96826 acquire_read_lock > 96824 acquire_write_lock > 96822 acquire_read_lock > > I'm not sure exactly what pages were being called in the log snippets > above, but this pattern is always the same. > > Chris > -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: Joe Schaefer wrote: [...] Looks very promising to me. Is there a way to tell PAUSE to index mod_perl's Apache::* modules from a bundle? If so, that might provide a decent solution for both mod_perl and libapreq (and other Apache::* modules that find themselves in a similar situation). I'm not sure I understand what you ask, Joe. The indexer indexes anything that upload to PAUSE (as long as you have perms). So we need release mp1 with a new package: Bundle::mod_perl1::core which has the same version as mod_perl.pm and mp2 distro with: Bundle::mod_perl2.0::core which has the same version as mod_perl.pm Now other packages can create a dependency on those packages, instead of mod_perl.pm. If you're going that route, Not really, I'm just discussing possible workaround. I really see that as being worse than introducing a new mod_perl2 package with mp2 and restoring all of mp1's CPAN indexing (including mod_perl.pm). But we don't want to rename the API. mod_perl.pm is a part of the API. I now think was a mistake for any of the Apache::* core modules to be indexed with mp1, because it looks like a wedding between the Apache:: APIs and the mp1 implementation of them. This is, IMO, the kernel of the complaints against the mp2 release plan. It has nothing to do with indexing of mp1 Apache::* core modules. When Randal has it's finger glued to the 'r' button, CPAN shell checks what are the *installed* modules and compares their version against the index. So if mp1 didn't index any of those, but mp2 did, you will still have a problem. Perhaps you were suggesting that none of the Apache::* core modules, but mod_perl.pm, should be indexed (both mp1 and mp2), in which case it makes sense. You still have a problem with mod_perl.pm. It's easy to fix, one could re-index anything w/o re-uploading the distro. One could argue that a user may create a dependency on a specific module in the core, because they don't care what modperl version is supplied, as long as that module has the right version, in which case they will have a problem, if core modules won't be indexed. Of course they could go and figure out what was the mp version when their prerequisite was first satisfied and ask for that mp version. But this non-indexing approach doesn't resolve the problem for 3rd party modules. -- __ Stas BekmanJAm_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 -- 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
Re: recommendations
On Fri, 31 Dec 2004, Stas Bekman wrote: > Octavian Rasnita wrote: > > Hi, > > > > I want to configure a production server that uses > > mod_perl and I don't know what version to choose because > > I see that mod_perl 2 is not stable yet. What do you > > recommend, to install Apache 1.3 and mod_perl 1 and use > > it until mod_perl 2 will be stable enough, or do you > > think that mod_perl 2 can be enough stable in order to > > be used for other purposes than testing? > > > > The programs for the production server are not ready > > yet, and it will take some more months until I will need > > to install the production server. > > I'd say go with mp2.0. If it helps, 2.0.0 should be out in > the next two weeks (we have about 3-4 remaining bugs to > resolve). If you encounter problems we fix them almost as > soon as you report them, so have no fear. I'd second that, especially, given some of your earlier messages, you're using Win32 in, at least, a development environment. mp1 on Win32 suffers from some serious limitations as far as threading is concerned: http://perl.apache.org/docs/1.0/os/win32/multithread.html which has been addressed in mp2: http://perl.apache.org/docs/2.0/os/win32/config.html Moreover, Apache2 itseld on Win32 is significantly faster and more stable on Win32 (and other non-Unix platforms): http://httpd.apache.org/docs-2.0/new_features_2_0.html due to a larger reliance on native platform implementations. -- best regards, randy -- 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
Re: [mp1] Linking confusion
William McKee wrote: Thanks for the clear explanation of *.a and *.so files, Stas. I'm starting to grok how it works together. I've attached the diff to the install docs to this message which incorporates some of your notes about .so and .a files. I found this information hard to find while browsing Google, Perlmonks and the modperl docs. I hope that you will include them in some form. Thanks William, I've committed that with a few tweaks. Especially the last para. Please check that it still makes sense. -- __ Stas BekmanJAm_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 -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
(This email will also be posted to http://ali.as/devel/mod_perl2.html for future reading.) If I haven't addressed something in my summary please let me know in that thread on the modperl users list (let's not spread it over multiple lists). Thank you. Responding here as requested. Before I begin, since this is a much wider audience, a quick introduction. For anyone that doesn't know me, my name is Adam Kennedy. I'm the author of 56 CPAN packages, including several that deal with strange module loading situations, the open source tool CVS Monitor, I have a small company in Australia that is doing work on artificially-intelligent code generation, and I'm currently working on a grant from The Perl Foundation to complete PPI, the pure-perl perl parser, which is hoped to form the basis of many elements of the perl tool chain. I am qualified to address most of the points I'm making in this email. I normally keep mostly to myself and I'm not normally very visible in the perl book or speaking community. However, I seem to have become the point man for the perl community in regards to this problem. Or at least, I'm the only one with enough time to speak to the depth required to address this properly. I'll try address the points from the URL stas posted, and provide some additional information. http://perl.apache.org/docs/2.0/user/porting/porting.html#The_Conflict_of_mp1_vs_mp2_vs_mp22_vs_vs_mpNN I apologize in advance for the length of this post, but I feel it's important to make sure I provide as much detail as possible. For those in a hurry, I have summarized each section at the end. This is probably going to read a bit more like a paper than an email. On a personal note, I have to say I'm embarrassed for the perl community that this hasn't been addressed properly earlier, and I apologize to the early adopters in advance, as I suspect that by leaving it this late to be addressed properly there are going to be some ramifications no matter what happens. -- Motivations --- I'll start with a direct response to the URL. Why mod_perl2 didn't Rename its API The reason for not renaming mp2 core and 3rd party modules APIs to embed the version number like (mod_perl2, Apache2::Cookie, Apache2::Scoreboard, Apache2::SizeLimit, etc.) is very simple and logical. Even though the internals of mp2 core and 3rd party modules are totally different from their mp1 counterparts, for the most parts the user API hasn't changed at all. Renaming the API is counterproductive, as it'll will impose extra work on the modperl users, and dangerous as the added complication may drive the users away to use other similar technologies which don't have this kludge. I agree completely this principle, and it is indeed a positive goal. The only point I'm going to make here is that the API has indeed changed quite significantly. Apache 2 is not Apache 1. It is an entirely new product, "branded" under the same name, and appointed the official successor by The Apache Foundation. Likewise, mod_perl 2 is a different product to mod_perl 1, with a different implementation, also "branded" under the same name. While the authors have attempted to make it similar to API 1, they have not done this sufficiently to make it compatible. In the vast majority of cases, a perl Apache module that runs under mod_perl 1.0 will not run under mod_perl 2.0 without at least some degree of modification. Even a very simple module that does not in itself need any changes will at least need the mod_perl 2.0 Apache modules loaded, because in mod_perl 2.0 basic functionality, such as access to the request object and returning an HTTP status, is not found where, or implemented how it used to be in mod_perl 1.0. API 2 is incompatible in almost all cases, although it does make it somewhat easier to port to than if it were _completely_ incompatible. An extremely long list of the various incompatibilities is listed at the following URL. http://perl.apache.org/docs/2.0/user/porting/compat.html In addition, now that we are getting closer to release, there seems to a second argument creeping in that it is also a "branding" issue. This is dangerous thinking, as is any situation where marketing decisions can alter technical decisions. Small decisions without understanding tend to have large cascading results. (Randy Sims) > More generally, we want a way to say that although distributions > may have the same name, they are fundamentally different in some > way. Yes that is twisted, but there does not seem to be a > reasonable alternative; > > Remember the real problem is we can't convey this information by > version number because of established (non)convention, not that > the distribution should be given a different name--it's a branded > product, and you don't change the packaging for fear of confusing > consumers. Thus we need a way to identify the change for CPAN > clients such as search.cpan and CPAN+, etc. Whether
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Stas, that was a a very useful summary of the issues -
thanks for putting that together!
On Fri, 31 Dec 2004, Stas Bekman wrote:
> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> >
> >>Joe Schaefer wrote:
> > [...]
> > I now think was a mistake for any of the Apache::* core modules
> > to be indexed with mp1, because it looks like a wedding between
> > the Apache:: APIs and the mp1 implementation of them. This is,
> > IMO, the kernel of the complaints against the mp2 release plan.
>
> It has nothing to do with indexing of mp1 Apache::* core
> modules. When Randal has it's finger glued to the 'r'
> button, CPAN shell checks what are the *installed* modules
> and compares their version against the index. So if mp1
> didn't index any of those, but mp2 did, you will still
> have a problem. Perhaps you were suggesting that none of
> the Apache::* core modules, but mod_perl.pm, should be
> indexed (both mp1 and mp2), in which case it makes sense.
>
> You still have a problem with mod_perl.pm.
To (partially) get around this CPAN.pm 'r' problem of
recommendations of available upgrades, what about, in the
mp2 package, use a no_index in META.yml to tell PAUSE not to
index the mp2 modules that have the same name as mp1
counterparts:
Apache::Log
Apache::PerlSections
Apache::Resource
Apache::SizeLimit
Apache::Status
Apache::URI
Apache::Util
That would mean in a Makefile.PL prerequisites section
that one couldn't use these to specify an mp2 version,
but that's perhaps not too much of a problem, as there's
other mp2-specific modules that can be used.
There's still mod_perl.pm in both packages, though. In mp2,
this is just something to define the version, and also to
provide a NAME pod section (if I remember correctly, this
was inserted for the benefit of search.cpan.org, to get an
abstract for the package). Not indexing mp2's mod_perl.pm
shouldn't affect search.cpan.org (I believe), as it
doesn't rely on the PAUSE indices, but it would
mean that one couldn't use (the useful)
PREREQ_PM => {mod_perl => 1.99}
in a 3rd party Makefile.PL to specify mp2. Instead, what
about adding a mod_perl2.pm to the mp2 distribution, just
again defining the version, so that one could use
PREREQ_PM => {mod_perl2 => 1.99}
mod_perl.pm would still be provided in the mp2 package
(just not indexed by PAUSE), so that constructions like
if ($mod_perl::VERSION > 1.99)
would still work.
The use of a Bundle in a prerequisite is similar, but the
thing with those (if I understand the usage correctly) one
must explicitly specify a package version to use, so that if
a later version of a package is released, one must update
the Bundle file to use that package, if desired.
--
best regards,
randy
--
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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Randy Kobes wrote:
Stas, that was a a very useful summary of the issues -
thanks for putting that together!
:)
On Fri, 31 Dec 2004, Stas Bekman wrote:
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
I now think was a mistake for any of the Apache::* core modules
to be indexed with mp1, because it looks like a wedding between
the Apache:: APIs and the mp1 implementation of them. This is,
IMO, the kernel of the complaints against the mp2 release plan.
It has nothing to do with indexing of mp1 Apache::* core
modules. When Randal has it's finger glued to the 'r'
button, CPAN shell checks what are the *installed* modules
and compares their version against the index. So if mp1
didn't index any of those, but mp2 did, you will still
have a problem. Perhaps you were suggesting that none of
the Apache::* core modules, but mod_perl.pm, should be
indexed (both mp1 and mp2), in which case it makes sense.
You still have a problem with mod_perl.pm.
To (partially) get around this CPAN.pm 'r' problem of
recommendations of available upgrades, what about, in the
mp2 package, use a no_index in META.yml to tell PAUSE not to
index the mp2 modules that have the same name as mp1
counterparts:
Apache::Log
Apache::PerlSections
Apache::Resource
Apache::SizeLimit
Apache::Status
Apache::URI
Apache::Util
That would mean in a Makefile.PL prerequisites section
that one couldn't use these to specify an mp2 version,
but that's perhaps not too much of a problem, as there's
other mp2-specific modules that can be used.
To start with, are we really interested to workaround for the mp-core,
ignoring the identical problem with multiple 3rd party modules? I fail to
see how providing a workaround for the core, relieves the problem, as 3rd
party modules (which are many more than the core) will bother users just
as well.
There's still mod_perl.pm in both packages, though. In mp2,
this is just something to define the version, and also to
provide a NAME pod section (if I remember correctly, this
was inserted for the benefit of search.cpan.org, to get an
abstract for the package). Not indexing mp2's mod_perl.pm
shouldn't affect search.cpan.org (I believe), as it
doesn't rely on the PAUSE indices, but it would
mean that one couldn't use (the useful)
PREREQ_PM => {mod_perl => 1.99}
in a 3rd party Makefile.PL to specify mp2. Instead, what
about adding a mod_perl2.pm to the mp2 distribution, just
again defining the version, so that one could use
PREREQ_PM => {mod_perl2 => 1.99}
mod_perl.pm would still be provided in the mp2 package
(just not indexed by PAUSE), so that constructions like
if ($mod_perl::VERSION > 1.99)
would still work.
-1, that will be very confusing as people will start using it for other
things. We will end up with some code requiring mod_perl.pm and other
mod_perl2.pm.
The use of a Bundle in a prerequisite is similar, but the
thing with those (if I understand the usage correctly) one
must explicitly specify a package version to use, so that if
a later version of a package is released, one must update
the Bundle file to use that package, if desired.
The idea was to have the Bundle included in the same distro, so when a new
mod_perl.pm is released, the Bundle will be updated too. I prefer the
Bundle workaround vs. mod_perl2.pm, since the former makes it clear that
it's only a CPAN thing and not to be used at the real code (other than in
prerequisite hash.
--
__
Stas BekmanJAm_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
--
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
Re: [mp1] Linking confusion
On Fri, Dec 31, 2004 at 02:02:59PM -0500, Stas Bekman wrote: > Thanks William, I've committed that with a few tweaks. Especially the last > para. Please check that it still makes sense. Looks fine except for a couple of typos (dangling quote mark and mispelled 'should'). Also, now that I'm a bit more knowledgeable about the subject matter, I was able to find this reference[1] in your docs which I've added to the attached patch. William [1] http://perl.apache.org/docs/1.0/guide/install.html#libperl_so_and_libperl_a -- Knowmad Services Inc. http://www.knowmad.com --- /tmp/install.pod.orig 2004-12-31 15:07:11.0 -0500 +++ /tmp/install.pod.wlm2004-12-31 15:04:56.0 -0500 @@ -688,7 +688,7 @@ that comes with Perl source. =for html Also see http://modperlbook.org/html/ch15_04.html";>"Chapter 15.4 - Perl +href="http://modperlbook.org/html/ch15_04.html";>Chapter 15.4 - Perl Build Options" from http://modperlbook.org/";>Practical mod_perl. @@ -721,16 +721,13 @@ Some distributions (notably Debian) have chosen to put F and F into the global library loader path (e.g., F) which will cause linking problems when compiling mod_perl -(if compiling against static perl), in which case you should move aside +(if compiling against static perl), in which case you hould move aside the F while building mod_perl or else will likely encounter further errors. If building against the dynamic perl's F, you may have similar problems but at startup time. It's the best to get rid of perl that installs its libs into F (or similar) and reinstall a new perl, which puts its library under the perl tree. -=for html Also see http://perl.apache.org/docs/1.0/guide/install.html#libperl_so_and_libperl_a";>libperl.so -and libperl.a. -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Stas Bekman <[EMAIL PROTECTED]> writes:
> Randy Kobes wrote:
[...]
>> There's still mod_perl.pm in both packages, though. In mp2,
>> this is just something to define the version, and also to
>> provide a NAME pod section (if I remember correctly, this
>> was inserted for the benefit of search.cpan.org, to get an
>> abstract for the package). Not indexing mp2's mod_perl.pm
>> shouldn't affect search.cpan.org (I believe), as it
>> doesn't rely on the PAUSE indices, but it would
>> mean that one couldn't use (the useful)
>> PREREQ_PM => {mod_perl => 1.99}
>> in a 3rd party Makefile.PL to specify mp2. Instead, what
>> about adding a mod_perl2.pm to the mp2 distribution, just
>> again defining the version, so that one could use
>> PREREQ_PM => {mod_perl2 => 1.99}
>> mod_perl.pm would still be provided in the mp2 package
>> (just not indexed by PAUSE), so that constructions like
>>if ($mod_perl::VERSION > 1.99)
>> would still work.
>
> -1, that will be very confusing as people will start using it for other
> things.
I'd like to see that -1 backed up with a technical objection;
lots of people are saying that "very confusing" isn't a satisfactory
explanation. The advantage of the additional mod_perl2.pm package
is that it is indexable in parallel with the existing mp1 tarball.
For mp2-only products, this would seem to be an advantage because
they now have an easy way of asserting that fact in their prereqs.
mp1-only products would need a way of saying "hold on, I'm not mp2
compatible yet!", which is something a test suite or a load-time
check will take care of. Cross-compatible products would be
unaffected.
What's the downside? That folks listing mod_perl 1.99 as a prereq
can't be satisfied? That's something that may change in the future,
so I'm not worried about that problem.
> We will end up with some code requiring mod_perl.pm and other
> mod_perl2.pm.
That's ok with me.
>> The use of a Bundle in a prerequisite is similar, but the
>> thing with those (if I understand the usage correctly) one
>> must explicitly specify a package version to use, so that if
>> a later version of a package is released, one must update
>> the Bundle file to use that package, if desired.
>
> The idea was to have the Bundle included in the same distro, so when a
> new mod_perl.pm is released, the Bundle will be updated too. I prefer
> the Bundle workaround vs. mod_perl2.pm, since the former makes it
> clear that it's only a CPAN thing and not to be used at the real code
> (other than in prerequisite hash.
Err, but then folks would need to adjust their prereqs (from say
"Apache::Resource" to "Bundle::mod_perlX"), right? Why do you see
this as preferable to the mod_perl2.pm solution?
--
Joe Schaefer
--
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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Randy Kobes wrote:
[...]
There's still mod_perl.pm in both packages, though. In mp2,
this is just something to define the version, and also to
provide a NAME pod section (if I remember correctly, this
was inserted for the benefit of search.cpan.org, to get an
abstract for the package). Not indexing mp2's mod_perl.pm
shouldn't affect search.cpan.org (I believe), as it
doesn't rely on the PAUSE indices, but it would
mean that one couldn't use (the useful)
PREREQ_PM => {mod_perl => 1.99}
in a 3rd party Makefile.PL to specify mp2. Instead, what
about adding a mod_perl2.pm to the mp2 distribution, just
again defining the version, so that one could use
PREREQ_PM => {mod_perl2 => 1.99}
mod_perl.pm would still be provided in the mp2 package
(just not indexed by PAUSE), so that constructions like
if ($mod_perl::VERSION > 1.99)
would still work.
-1, that will be very confusing as people will start using it for other
things.
I'd like to see that -1 backed up with a technical objection;
lots of people are saying that "very confusing" isn't a satisfactory
explanation.
OK, here it is the same thing, worded more technically:
We can't have mod_perl.pm and mod_perl2.pm in the same distro. There
should be only one API and not two that do the same thing.
The advantage of the additional mod_perl2.pm package
is that it is indexable in parallel with the existing mp1 tarball.
For mp2-only products, this would seem to be an advantage because
they now have an easy way of asserting that fact in their prereqs.
mp1-only products would need a way of saying "hold on, I'm not mp2
compatible yet!", which is something a test suite or a load-time
check will take care of. Cross-compatible products would be
unaffected.
What's the downside? That folks listing mod_perl 1.99 as a prereq
can't be satisfied? That's something that may change in the future,
so I'm not worried about that problem.
Sorry, Joe, but that's not enough. If you do mod_perl2.pm. You will need
to add APR{X}.pm and do the same for all 3rd party modules. Please stop
concentrating on the modperl-core and try to address the problem as a whole.
We will end up with some code requiring mod_perl.pm and other
mod_perl2.pm.
That's ok with me.
See above.
The use of a Bundle in a prerequisite is similar, but the
thing with those (if I understand the usage correctly) one
must explicitly specify a package version to use, so that if
a later version of a package is released, one must update
the Bundle file to use that package, if desired.
The idea was to have the Bundle included in the same distro, so when a
new mod_perl.pm is released, the Bundle will be updated too. I prefer
the Bundle workaround vs. mod_perl2.pm, since the former makes it
clear that it's only a CPAN thing and not to be used at the real code
(other than in prerequisite hash.
Err, but then folks would need to adjust their prereqs (from say
"Apache::Resource" to "Bundle::mod_perlX"), right? Why do you see
this as preferable to the mod_perl2.pm solution?
I've explained why in the last sentence above. It's clear that it's not
part of the API, whereas mod_perl.pm is a part of the API.
--
__
Stas BekmanJAm_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
--
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
Re: [mp1] Linking confusion
William McKee wrote: On Fri, Dec 31, 2004 at 02:02:59PM -0500, Stas Bekman wrote: Thanks William, I've committed that with a few tweaks. Especially the last para. Please check that it still makes sense. Looks fine except for a couple of typos (dangling quote mark and mispelled 'should'). Also, now that I'm a bit more knowledgeable about the subject matter, I was able to find this reference[1] in your docs which I've added to the attached patch. Thanks William, committed. For the future please note that internal links are done like so: Also see L. I've adjusted that. also your patch was reverted :) -- __ Stas BekmanJAm_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 -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
I'm going to chime in, as someone working on a suite of modules that are
intended to eventually work with apache 1.x and 2.x. First, I agree with
this:
On 12/31/04 2:27 PM, Adam Kennedy wrote:
> For the moment, I'm asking just that the release of mod_perl 2.0 be put
> on hold until this problem, and it is most definitely a show-stopper of
> a problem, is resolved in it's entirety. And to the satisfaction of both
> the mod_perl developers and the perl community.
Next, I'm going to put in my vote for a new namespace, be it Apache2:: or
something else.
As has been pointed out, the APIs of mod_perl 1 and 2 really aren't
compatible--nor should they be. Apache 2 (the http server) took the 2.x
change as an opportunity to Do It Better, and so should (and has, for the
most part) mod_perl 2.
Even as someone writing several modules that will need to work with both
versions of mod_perl, I'd still rather have a clean split. I can abstract
things easier (based on $ENV{'MOD_PERL'} most likely, but many mechanisms
are possible) if there's a clean namespace split. Let me unify my API.
I'll hide the Apache:: and Apache2:: (or whatever) differences behind the
scenes.
As for third party Apache:: modules, let them eat port. I'd rather see them
make Apache2:: ports that take full advantages of the brave new world of
MP2. And I'm sure many (most?) authors would like a chance to revisit their
APIs anyway.
Porting while maintaining API compatibility and staying in the same
namespace seems like work to me. Porting to Apache2:: and being able to
clean up the sins of the past and do cool new stuff in the process seems
like fun. Call me crazy, but I think this is a common view among
programmers (in the case of 3rd party Apache:: modules, whether they're the
original authors or not).
Finally, I don't see a proliferation of Apache2_2::, Apache3::, etc.
namespaces as a real threat. The policy is simple: CPAN namespace == an
API. If apache/httpd 2.[2-9] or 3.x requires or would benefit from a new
mod_perl *API*, guess what, then you get to pick a new CPAN namespace. If
not, you can continue to use Apache2:: (or whatever) regardless of how
apache/httpd server changes behind the scenes.
This line of thinking eventually leads to another simplifying decision: the
mod_perl API versioning and branding should be divorced from Apache
Foundation branding and versioning where possible. If Apache 3.x doesn't
warrant mod_perl API changes, then there's no reason the Apache2:: namespace
can't serve it. Ah yes, but the "Apache" name is in both places, so that
argues for maybe ModPerl::, ModPerl2:: or MP2:: or whatever instead of
Apache.*::.
My summary:
1. Hold off on the offical release of mod_perl 2 until this is settled.
2. I think the simplest solution is also the cleanest and the most
forward-thinking, even if it is more work: a new CPAN namespace for mod_perl
2, and a divorce of mod_perl branding and versioning from the Apache
Foundation's branding and versioning.
-John
--
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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Adam Kennedy wrote: [...] [my apologies if I've over-trimmed Adams original, but it's hard to keep focused on such a huge email] Why mod_perl2 didn't Rename its API The reason for not renaming mp2 core and 3rd party modules APIs to embed the version number like (mod_perl2, Apache2::Cookie, Apache2::Scoreboard, Apache2::SizeLimit, etc.) is very simple and logical. Even though the internals of mp2 core and 3rd party modules are totally different from their mp1 counterparts, for the most parts the user API hasn't changed at all. Renaming the API is counterproductive, as it'll will impose extra work on the modperl users, and dangerous as the added complication may drive the users away to use other similar technologies which don't have this kludge. I agree completely this principle, and it is indeed a positive goal. The only point I'm going to make here is that the API has indeed changed quite significantly. Adam, you didn't quote the whole story here. The unquoted parts explain that's it's not only the issue with those parts of the API that did change. http://perl.apache.org/docs/2.0/user/porting/porting.html#Why_mod_perl2_didn_t_Rename_its_API Summary: API 2 is similar to, but fatally incompatible with API 1 By reading the whole section quoted above you will see why the above is not so as you say. -- Implementation -- While the motivation for maintaining the same API is correct, the implementation in its current state would appear to be less than ideal. mod_perl2 proposes to use an entirely new technique, one that has never before been used in a non-Acme:: perl package, and involves creating a parallel module path called Apache2/. [...] Because of this, the method used by Apache2 can most likely ONLY ever be used by Apache2 and can never be a more general feature, without serious changes to the entire perl module-resolving infrastructure, or a different implementation. Summary: The mechanism used by Apache2 is mutually exclusive with any other module using a similar mechanism. The end of http://perl.apache.org/docs/2.0/user/porting/porting.html#__pm__so__Files_Collision addresses this issue. Apache2 workaround is needed for those several users who want to have both generations under the same perl. 99.9% of users do *not* need to use this workaround. So that issue is moot if you ask me. Talking about generic solutions, if the problem didn't exist, only.pm wasn't written http://search.cpan.org/dist/only/ the URL above also explains why we didn't use only.pm --- API Overloading --- In establishing a parallel module tree that provides a similarly-named but different set of modules, the "use Apache2;" statement is "overloading" the entire CPAN namespace at an API level, allowing multiple "stable and supported" but fatally incompatible APIs to co-exist in the same location in the perl namespace. An important note: Not at runtime! > For example: there are two internally incompatible versions > Apache::Scoreboard (but which otherwise work identically for > users): http://search.cpan.org/~stas/Apache-Scoreboard-2.02/ > http://search.cpan.org/~dougm/Apache-Scoreboard-0.10/. > Notice that each generation is developed and maintained by a > different developer. Under normal circumstances in perl development, the API is either changed, making the previous version redundant. (and potentially causing damage in the process) or kept fully compatible with previous versions (preferably). The concept that an arbitrary number of different APIs should LEGALLY be able exist in the same namespace and ALL be considered to be supported at the same time is so unprecedented in the perl world that it has not even had a name until now. You must be kidding, Adam. What about GD, SQLite, Sun::Solaris::*, etc. For ease of reference, the term "API Overloading" is now starting to be used to refer to this idea of having multiple "current" APIs supported within a single namespace. This sort of technique is much more accepted in the C world, which has a much more sophisticated library versioning and linking system with ld and .so files. Agreed. But modperl is definitely not the first module to encounter this problem. mp2 provides a Perl API for libapr and libaprutil projects (which can be used even if you don't run modperl). At the moment there is libapr 0.9.x, 1.x and 2.x will be released soon. All those are partially incompatible. Since modperl provides only a partial mapping to the C APR API the mod_perl users so far can run their code unmodified no matter whether they have libapr-0.9, libapr-1.0 or libapr-2.0 installed. If we were to embed the numbers in the API, users would have had to rewrite their application to make it support each new release of APR. Let's look at the multiple C libraries you have installed on your machine. 99% of the libraries do not change their API naming when
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
On 12/31/04 4:40 PM, Stas Bekman wrote: > Finally you don't want to use it - don't use it. It's an open source > software, it will succeed or fail by *its own merits* and not because the > infrastructure has a long known problem but is not willing to evolve. > > And to repeat this again. If you install only mp2 under the given Perl, > all those hours spent in trying to stop the evolution are a total waste, > since mp2 has no problem what so ever. None of the problems discussed in > this and many other similar threads is relevant. They are relevant only to > a few people who for some reason want to have both modperl generations in > the same tree. And you will be able to count those with your fingers on > the left hand. So let's hurt 99.9% of users, because 0.1% will have it a > bit harder than the rest. I think the infrastructure thing is a red herring. Unless the "native" mod_perl 2 API is 100% compatible with mod_perl 1 (it isn't), mod_perl 2 shouldn't be in the same CPAN namespace as mod_perl 1 if mod_perl 1 will continue to exist (it will). This is regardless of whether or not I or anyone else plans to have both mod_perl 1 and 2 installed at the same time. It's simply The Right Thing to Do, IMO. It's also one of the easiest solutions for the mod_perl 2 core team. If third party Apache:: CPAN module authors have objections, let them speak up (although they probably won't change my opinion--see previous email). But so far, I mostly see mod_perl 2 core people making the third-party module argument by proxy (okay, granted, many of them are also third party Apache:: module authors...too many hats! :) Anyway, I don't think the mod_perl 2 core team has anything to fear from massive third-party Apache:: module abandonment. They'll be ported if there's a need, and more likely than if a port didn't have the opportunity to change the API as well as the implementation. -John -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes: Stas> 99.9% of users do *not* need to use this workaround. So that Stas> issue is moot if you ask me. You keep saying this like you believe it. In fact, the number keeps getting closer to 100% each time. This is pure, fabricated *fiction*. Four out of my five biggest customers *will* need to have both modperl1 and modperl2 in the same Perl installation tree on their development machines, because they'll need to start looking at how to port their work over, and they won't want to duplicate-install all the other modules they use into two different Perl installations on one box. Thus, even for just *my* customers, the number is 20%. Not 90%. Not 99%. Not 99.9%. Please wake up. Stas> So let's hurt 99.9% of users, because 0.1% will have it a bit Stas> harder than the rest. And you keep repeating the lie. Shame on you. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- 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
[Fwd: Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN]
John Siracusa wrote: On 12/31/04 4:40 PM, Stas Bekman wrote: Finally you don't want to use it - don't use it. It's an open source software, it will succeed or fail by *its own merits* and not because the infrastructure has a long known problem but is not willing to evolve. And to repeat this again. If you install only mp2 under the given Perl, all those hours spent in trying to stop the evolution are a total waste, since mp2 has no problem what so ever. None of the problems discussed in this and many other similar threads is relevant. They are relevant only to a few people who for some reason want to have both modperl generations in the same tree. And you will be able to count those with your fingers on the left hand. So let's hurt 99.9% of users, because 0.1% will have it a bit harder than the rest. I think the infrastructure thing is a red herring. Unless the "native" mod_perl 2 API is 100% compatible with mod_perl 1 (it isn't), mod_perl 2 shouldn't be in the same CPAN namespace as mod_perl 1 if mod_perl 1 will continue to exist (it will). This is regardless of whether or not I or anyone else plans to have both mod_perl 1 and 2 installed at the same time. It's simply The Right Thing to Do, IMO. And more than that, it fundamentally hurts everyone as it breaks an entire assumption of the language. Whether 99% (I have yet to see this number proven, perhaps a slashdot poll?) of the userbase have this problem "worked around" in the limited case of the application run-time environment, it STILL causes problems for those using both, AND it causes problem for ALL of the common perl infrastructure that has no choice BUT to hold both for AT LEAST 5 years, more likely 10. So you get bizarre problems like encountering something funny in your mod_perl2 program, going to search.cpan.org, or perldoc.com to look up that module and writing code against that online documentation, and it won't work, because the documentation doesn't match the API of what is actually running on the system. Are you, personally, willing to make the decision on behalf of the PMC and The Apache Foundation that nobody that uses mod_perl 2 is allowed to use any perl website? You cannot just pile up workarounds that work in a limited set of situations for a sufficiently high percentage of the user community and expect things not to still go funny everywhere else. Again, you have addressed ONLY the limited cases of installing for the end user, and runtime for the end user. (Assuming that the end user does not interact with any public perl resources while doing so). In addition to that... GD didn't change API, they changed backends. Other modules have changed API and announced that the old one is now redundant. Both are acceptable. What mod_perl is trying to do is have its cake and eat it too by using a new backend, AND using a new API, AND saying that the old API is still supported. This is what you are doing that is unprecedented. Ideally you would keep a back-compatible API, and the only other reasonable alternative is to announce that the mod_perl 1 API is now redundant and will no longer be supported. "mp2 is the future, mp1 is the past. As of today". Furthermore, despite trying to resist flaming, but if I can put a number of fully described problems in front of you, backed up at least for some of them by for all intents and purposes the ENTIRE perl community other than you, how on earth can you still disqualify that out of hand. When EVERYONE is telling you that you might be wrong, don't you at least owe it to them to wait before plunging the entire mod_perl world into controversy by release something that won't work on the perl infrastructure, and that nobody wants? I would suggest that these sorts of decisions are a call for the [EMAIL PROTECTED], rather than any single individual developer on the project. Firstly, if we should pause to deal with near-universal concerns from the perl community. Secondly, if you should end-of-life mod_perl 1 when you release mod_perl 2 over the top of it. For starters... Now I have an 800km drive in 5 minutes. I'll provide some details answers to your other comments at the other end. Adam -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Randal L. Schwartz wrote: Four out of my five biggest customers *will* need to have both modperl1 and modperl2 in the same Perl installation tree on their Bullcrap - I would say that sep perl installs is not enough! Personally I would hate to work for anyone who does insists on dev/testing on live systems - they deserve what they get - outages *and* public ridicule. And please don't give me that it's *sooo* hard to set up. One of our clients have connections to payment, billing and mobile networks that require major effort and cost for test config and even with this overhead they see the advantages of a distinct test system. I would hope that your clients (as part of the disaster recovery plan) would have a detailed list of software installed (including perl modules , configuration files etc) so that in the worst case scenario you can replicate the live systems without having to retest due to "possible" changes - frequent vaping and re-installing of the test system is a good way to ensure the disaster recovery plan actually works... Clients I know running Apache based systems have upgraded to AP2/MP2 and in the process, have planned upgrades of new hardware to allow // running as part of the migration process. Commonly hardware cost is often less or equal to the cost of executing a system test plan. Often they have been running MP1 for a number of years and the hardware has come to its "end of life". If you are doing anything commercially sensitive I would expect due dilligence to require // running at a min. Jacqui p.s. Under windows (perl 5.6 for MP1 and 5.8.x for MP2) forcing distinct perl installs. -- 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
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Stas> 99.9% of users do *not* need to use this workaround. So that Stas> issue is moot if you ask me. Randal> You keep saying this like you believe it. In fact, the number keeps Randal> getting closer to 100% each time. Randal> This is pure, fabricated *fiction*. For me, this ends up being the sane way to do it, for the same reason I install Apache2 into a separate tree. MP2 isn't simply a collection of modules. It's an embedded interpreter with pieces that enter the Apache tree. I realize this isn't the big issue, but comparisons to other Perl "generations" don't quite match for this reason. Randal> Four out of my five biggest customers *will* need to have both Randal> modperl1 and modperl2 in the same Perl installation tree on their Randal> development machines, because they'll need to start looking at how to Randal> port their work over, and they won't want to duplicate-install all the Randal> other modules they use into two different Perl installations on one Randal> box. I may be the exception, but I've done a lot of porting already and would never go about it the way you describe. An mp2 install (regardless of the solutions at hand) virtually demands a clean Perl install (usually on a clean box as well), and duplicate installs of dependency modules is typical on any migration project I do in the interest of having a sane development environment and duplicate-ability (not unlike the separate apache2 tree itself). I then introduce the code to be ported into the new environment in much the way that the mp2 docs describe. Whether users *will* port this way is debatable. But if forced, I'd say they're being forced into the preferable scenario anyhow. I agree with Adam's points on the API, but think Stas is correct that most users will not have both "generations" installed in the same tree. The fact that mp2 is such a radical departure from mp1 is to me an argument for porting into a "clean" tree, in much the same way that the API incompatibilities are others' argument for a change of namespace. :-) -- 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
