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 more than one > generation of a distribution can be installed is an important side > issue, but it's a side issue to the bigger problem of identifying > different "generations" for CPAN clients. > > As I noted in one of previous posts, there are admittedly a lot > of implications for such a seemingly small change.
Summary: API 2 is similar to, but fatally incompatible with API 1
----------------------------------------------------------
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/.
A special use statement "use Apache2;" modifies the normal perl @INC include path to add a "$path/Apache2" that is checked before the normal paths.
In effect this creates a scenario where you have an alternative plane of
modules, named like the normal perl module namespace, but which are
allowed to act differently and provide a different API while in this Apache2 environment.
At first glance, from a tactical (close in) point of view, this is viable. A number of modifications can be made to the installer,
and every mod_perl2 application in the world can have "use Apache2"
added to the start, and it would seem to work just fine.
We agree that this solution is able to (theoretically) install and (provably) load and run.
However, before I get into the biggest problem, I'd like to note that the code that does this is designed rather less than scalably.
The mechanism used is mutually-exclusive to any other implementation of the same technique. Should DBI and CGI release a DBI API 2 and CGI API 2 in their respective namespaces, you would need to do the following.
# Set the alternative module planes use DBI2; use CGI2; use Apache2;
use DBI; use CGI::Carp; use Apache::Module;
In addition, because each adds additional directories, you would end up with a path
like... (assuming ONLY one element '.' in @INC, multiply by 6-10 for real world cases)
@INC = './Apache2/CGI2/DBI2',
'./Apache2/CGI2',
'./Apache2',
'./CGI2/DBI2',
'./CGI2',
'./DBI2', '.';... or some other suitably horrible result. The number of paths in @INC
would be increased by 2^N, where N is the number of module implementing
the same technique, and any application that uses both Apache2 and DBI2
would need to write many different hooks to all sorts of things in order to work.
Likewise, the number of implementations of each module will also need to increase accordingly, so that Apache2 Apache:: modules using DBI1 DBI:: will have to be ported up to use DBI2 DBI::, and CGI2 CGI:: instead of CGI1 CGI::. Confusing right?
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.
-----------------------------------------------------------
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.
> 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.
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.
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 they release a new version. Take for example the Berkley DB library. It had dbopen(3) for its 1st generation, and 2nd, and 3rd, and 4th.
The critical point I'd like to make here is that the Perl APIs APR:: and APR::Util:: are a totally different entity in a totally different layer to the underlying libapr and libaprutil libraries, although the two APIs have for clarity obviously been named to reflect the names of the underlying C APIs used to implement them.
As a perl module author, we are generally expected to maintain API compatibility and stability regardless of the underlying implementation. This is encapsulation done correctly.
If the underlying library changes, the perl author has three choices (although he can use a mix of several or all of them).
1) Change to the new underlying C API without changing the Perl API of a similar name.
2) Change the Perl API and make a judgment call on behalf of your user base that the damage caused to them from the change is worth the resulting improvements to the API.
3) Implement a new API, completely different from the first, name it
differently, and allow the user to use that instead, and convert in their own time.
Which of these three is done is a judgment call best made by the author and/or lead developers.
The only thing available to the Perl user that helps to provide choice over which version (and thus API) of a module you use is the only.pm module, which implements API security by saying.
"I do not want to upgrade to the versions outside of this known range in case the API changes and breaks my code"
only.pm allows the user to secure the APIs they use against damage by the author, by allowing the user to intentionally prevent the use of unknown versions of modules.
Summary: API overloading is the provision of multiple supported but incompatible APIs within the same perl module name.
Summary: Perl currently cannot support API overloading, but can provide API security
--------------------------------------------------------
API overloading should not be supported in Perl 5 -------------------------------------------------
While it may well load correctly, mod_perl2 (or more specifically the concept of API overloading that mod_perl2 uses to avoid changing name) is increasingly being considered dangerous, and a consensus has emerged (especially since the greater attention brought to it by the Release Candidate announcement) that the entire concept of API overloading is either not possible, or could potentially be the cause of massive damage to users.
There are a number of reasons, largely at a strategic and tool-chain level, rather than at a line-by-line code level.
Primarily, the concept appears to be incompatible with CPAN, man, POD, all standard perl tools, all cpan.org websites (rt.cpan.org, cpanratings.cpan.org, search.cpan.org), all known Perl wikis, and all known module installers, and the debian perl module naming scheme.
All of these, and all unknown-to-us private toolchains, and perl's module resolving mechanism, would all need to be changed to implement support for API overloading.
I've outlined the various problems and some more general information in my previous email to the dev@perl.apache.org mailing list, which you may wish to read at this point.
http://mathforum.org/epigone/modperl-dev/strungbandswem/[EMAIL PROTECTED]
I won't go into any more detail on the matter, other than to simply
state the following. And on this point I have as near to the complete support of the perl community as it is possible to get given the urgency of resolving this problem.
"API overloading is not, and should never be, supported in perl 5"
Those that I have talked about this to in just the last 48 hours willing to be named include,
Myself Micheal Schwern Autrijus Tang Randal Schwartz Marcus Ramburg Ben Mankin (shevek) Corwin Brust
There are a similar number of eminent perl/CPAN authors who are also against it that either can not or do not wish to be named in public.
The CPAN authors I have had time to consult with between them are personally responsible for over 500 individual CPAN packages.
The p5p mailing list has also stated (in other terms, but several times) that it does not want or is spooked by having multiple supported APIs for a single module name, including (I believe), the authors of PAUSE, DBI, CPAN.pm, MakeMaker, the perl 5.10 pumpking, and more. The most common term used is "generations".
(Ken Williams) > This idea of "generations" as a similar-but-different counterpart > to "versions" makes me very uncomfortable, but I can't quite put > my finger on why. ... > I think it's a *good* thing that releasing backwards-incompatible > modules is frowned upon right now. I think it's a *bad* thing when > GD or mod_perl or whatever use the same namespace for essentially > a different module. ... > As I outlined in my message, and as Jos outlined in his, I don't > see the "generation" concept as workable in the Real World, at > least in its present form.
(Jos Boumans) > I concur. The solution of 'generations' is just Yet Another Way > to describe dependencies and compatibilities (and not one that > i think will solve the issue described by stas).
(Andreas Koenig) > I'm sorry, but I have my doubts that this is going to fly. > The approach doesn't seem conservative enough. > > (Stas) > > the index format should be changed to include not only the latest > > version, but instead generation:version pairs > > I do not see a format that would do so without confusing > older versions of CPAN.pm or CPANPLUS.pm. > > I may have missed some discussion on this, but I also do not see > a generic way to solve the global @INC problem for an unlimited > number of generations of a package.
(Randal Schwartz) > Stas> Ideally the CPAN+ client should be able to query the user's > Stas> system for what Apache version it has installed and according > Stas> to that information, choose the right mod_perl version. > > This is where you keep getting into trouble. > > I could have *both* versions of Apache installed. In fact, I do. > > There must be a way to have one @INC deal with *multiple* > incompatible APIs. > > Come up with a solution to deal with that. You're still solving > the wrong problem. > > This is why I keep freaking out.
Please note I am quoting Ken, Andreas and Jos only and have not spoken to them directly at this point, but I believe they are lurking. I also have not yet had a chance to talk to Larry Wall or Damian Conway (both are known to be adverse to taking positions without long periods of review).
Additionally and more importantly, I have not yet encountered _any_ single perl 5 contributor outside of the core mod_perl developers that support the idea of multiple supported-but-incompatible APIs within a single namespace.
I'd like to restate that on other than this one point I do not claim the explicit support of anyone else in the Perl community. In addition, this ONLY applies to Perl 5. Perl 6 is a generational change in perl, and all bets are still off :)
Please also note again I am talking about APIs and not implementations. Authors are free, as usual, to upgrade the version or implementation without changing the API. If an API is changed, the old API becomes redundant.
> What's going to happen when mod_perl 2.0 is released on CPAN? > All users will then get mod_perl 2.0 fetched even if they > want mod_perl 1.0. mod_perl 2.0 doesn't replace mod_perl 1.0, > so using the-latest-version-is-the-one-you-want approach doesn't > work here. Have you discussed this issue?
Multiple versions for a single module are supportable, multiple APIs are not.
Summary: API overloading is not supported in Perl 5 or CPAN. Period.
-------------------------------------------------------------
Please note that at this point we have covered what I feel to be the core issue here.
That is, in order to allow them to keep using Apache:: while still supporting the current API 1 Apache::, the mod_perl2 developers
have implemented an API overloading mechanism.
A consensus has been reached that this overloading concept is "bad" (at best) or "fundamentally incompatible with perl 5 and CPAN" (at worst), and that it should not be supported in perl 5.
Again, further details are available at the earlier URL.
From this point on you should consider everything speculative on my part, as I don't assume to know the "best" way of deciding how to remove the API overloading "feature" from mod_perl 2.0.
Summary: Everything below here is speculative or personal observations.
-------------------------------------------------------------
mod_perl2 needs a private set of tools --------------------------------------
I'll try to quickly cover the rest of the document, although much of
this is moot until the underlying problem of API overloading in Apache:: is resolved.
Most of it relates to a set of "workarounds" to make up for the fact
that perl 5 cannot support the API overloading feature represented by
"use Apache2;". The position would appear to be that if mod_perl2 can
accumulate a sufficiently large set of workarounds, and workarounds for
the workarounds, and so on, then everything will be ok. And eventually perl 5 will come to the party.
Documentation and Manpages
If mp2 installs its .pm files under Apache2/ perldoc won't find those. The alternative solution is to use mp2doc provided by mp2, which will find the right docs.
As for manpages, only one set of manpages can be installed and this true for any project (e.g. You can have several generations of the same C library installed, but you will have only one set of manpages).
So use mp2doc or the online docs: http://perl.apache.org/docs/2.0/api/ which you can also build locally.
As mentioned previously mod_perl2 is fatally incompatible with _all_
known documentation systems that use modules as a key (which is pretty much all of them).
The workaround chosen by mod_perl2 is to fork perldoc and provide a mod_perl2-specific version of the standard perldoc tool, named mp2doc.
The same would appear to hold true for any other module that implements API overloading and add their own parallel module plane as well.
One would need to use cgidoc to access CGI API 2 docs for CGI::, dbidoc
to access the DBI API 3 docs for DBI::, and to take it to extremes,
mp22doc to access the mod_perl API 2.2 documentation for Apache:: (which again is an extreme and of course won't happen).
The standard CPAN shell, 'cpan' (which calls perl -MCPAN -e 'shell') will also not be able to see mod_perl2.
CPAN Shells
In case you have mp1 and mp2 under the same perl and mp2 is installed under the Apache2/ subdirectory, in order for CPAN shell to find you mp2 modules you need to invoke it as:
% perl -MApache2 -MCPAN -eshell
For CPANPLUS:
% perl -MApache2 -MCPANPLUS -eshell
If you have only mp2 and you didn't ask to install it under the Apache2/ subdirectory, no special invocation technique is required.
One mod_perl mailing list ([EMAIL PROTECTED]) recently proposed that 'mp2cpan' be created to do this.
The same will be true with new forked versions of every standard perl tool, and on every alternative API plane.
Summary: No documentation systems will be able to see mod_perl2 modules
Summary: No CPAN installer module will be able to see mod_perl2 modules
--------------------------------------------------------------
Workaround likely to accumulate indefinitely --------------------------------------------
Similar workarounds continue to be added as we get closer to release.
Here are some additional examples.
As a mod_perl2 module author, you cannot install a mod_perl2 module using the normal install processes.
In order to make mp2 co-exist with mp1 install, one needs to install mp2 modules in a sub-directory Apache2/. The modperl core installer will make sure that this happens if it detects that mp1 was installed. 3rd party modules writers need to use ModPerl::MM::WriteMakefile which will do the right thing. At run time loading Apache.pm will adjust @INC to include the right paths.
So you can't use the standard MakeMaker, mod_perl2 has forked that and produced it's own private version. Module::Build may be scriptable enough to do this merely with special instructions and not a forked version, but discussions are still ongoing.
Perl doesn't provide any support for multiple generations of the same project. There are a few workarounds:
1. install a different perl for each separate version of project, in which case there is no problem with co-existence.
2. install the second generation in some other directory and adjust @INC at perl startup, so that this new directory will appear first.
only and only::install (http://search.cpan.org/dist/only/) do exactly that.
mp2 users have to use one of these workarounds. In the case of the second workaround, mod_perl uses its own implementation, called Apache2.pm.
only.pm does this in order to implement API security, not to provide multiple "current" supported APIs.
But then again mod_perl2 has already forked the only.pm functionality and provided it's own private version.
As you can see, mod_perl2 is slowly going through the process of forking the entire perl tool chain, and parts of the perl core module functionality in order to workaround the use of an "feature" that will not be supported.
I would propose that this is going to continue to get worse.
Summary: mod_perl2 will need to fork a large part of perl core functionality
---------------------------------------------------
Why is this only happening now? -------------------------------
(Stas, dev@perl.apache.org) > I think it's up to users to make sure that this CPAN problem is > not dropped again for the third time in the last 3 years that > I've been raising this issue.
(From the document)
> Q. Why this issue was not resolved earlier?
>
> A. The issue was raised several times on the perl5-porters
> and cpan-discuss lists over the period of the last few years.
> But nothing was implemented. You can read the details:
>
> May 2003: >http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00220.html
>
> Oct 2003: >http://www.mail-archive.com/cpan-discuss@perl.org/msg00000.html
> Dec 2003: >http://www.mail-archive.com/cpan-discuss@perl.org/msg00033.html
>
> Dec 2004: >http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-12/msg00510.html >http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-12/msg00484.html
>
> Amongst other proposed solutions, Autrijus has posted a concrete
> solution to how to fix that: >http://www.mail-archive.com/cpan-discuss@perl.org/msg00012.html
Most of the conversations have been limited to issues of indexing and the support of multiple versions, or provisioning of additional version information or more complex dependency formats.
The general theme of the response across all these is that while it might be possible to do something to make it possible to download different versions or specify custom dependencies, perl has always specified that in order to change the API (and not the version or implementation) you have to make the old one redundant. This is how it has always been.
(Stas, on p5p) > I'll repeat in a few words the gist of the problem and the > solution that was agreed upon I believe at least year ago at this > very forum. > > There are several distributions on CPAN whose user API doesn't > change but internals are so different that it makes impossible > to support those in the same distro. This is the case with GD, > mod_perl, (Tk?) and I think a few other modules. Renaming those > modules just for the sake of renaming is creating useless work > for users, who will need to make loops in the air to support > several generations of the same code, when in fact different > generations will work just the same for them.
Stas is right on this point. When the API has not changed, we should not have to rename the modules just because the underlying implementation has changed.
Unfortunately, while the perl mailing lists may have some consensus that this should be the case, and that over time something may happen to resolve the type of situation thrown up by the GD disaster, mod_perl 2 is not currently a member of this group.
As has been established, mod_perl API 2 is a new API this is similar to, but fatally incompatible with, the current mod_perl API 1.
And perl will _not_ be supporting API overloading or multiple APIs in the same namespace without making the previous API immediately redundant.
Unfortunately, because it would appear that most of the conversations have been on technical internal issues without seriously discussing the core problem of non-redundant API change and the "use Apache2;" API overloading mechanism, the problem has continued to go unaddressed.
The imminent release of a production version of mod_perl that continues to have problems and could damage CPAN (but more on this later) has resulted in more people (including myself) taking a much more in-depth look at the core problem, resulting in this email, amongst others actions.
Summary: This is being addressed now because release is imminent despite the problem remaining.
------------------------------------------------------
A collection of possible solutions ----------------------------------
I am in no position to dictate to the mod_perl development team how this problem is to be resolved. I am not part of the mod_perl 2 team.
The following is what I would consider the set of theoretically possible solution to the problem. There may well be others.
1. Alter mod_perl API 2 to make it a 100% compatible super-set of mod_perl API 1
2. Move the mod_perl API 2 to an alternative namespace, say Apache2:: (which continues to be the one most perl people are suggesting)
2.1. Alter Apache::compat to provide Apache:: as an optional install on the Apache 2 server, allowing legacy mod_perl 1 applications to be moved to Apache 2 unchanged, while writing new applications in Apache2::
2.2. Early adopters already using mod_perl2 can simply apply s/\bApache::/\bApache2::/ to their applications and they should work unchanged.
(2 + 2.1 + 2.2 is what I would consider my solution, if _I_ were to be responsible for solving this... which I'm not...)
3. Release mod_perl2 in Apache::, but follow standard perl procedures and make the mod_perl 1 API immediately redundant and unsupported.
(Joe Schaefer on dev@perl.apache.org) > [*]- A month ago, I checked on the netcraft/securityspace > apache2 adoption rates, and it was about 1/6 of all > apache installations. *Many* people simply aren't ready > for apache2 yet, much less mp2.
4. Something I can't think of because I don't know the mod_perl 2 internals.
Summary: There are several ways in which the problem can be fixed
-----------------------------------------------------------------
Speculative future if mod_perl 2 is released as is --------------------------------------------------
Again, this is extremely speculative, but is what I suspect would happen if mod_perl2 is released in it's current condition.
Firstly, on release the mod_perl2 tarball will need to be immediately and "temporarily" locked out of the CPAN indexer to prevent forcing upgrades on every existing mod_perl1 installation, or to at least have CPAN say you have to upgrade to mod_perl2 every single time you install Apache::Anything.
(Randal Schwartz) > ... modperl2 should remain de-listed from the CPAN until these > issues are resolved. As long as the latest CPAN.pm "insists" > that update my modperl1 distro by installing modperl2(!) > to update Apache::SizeLimit and Apache::Resource, your > modperl2 distro is broken. > > The temporary solution is to delist modperl2 entirely. ... > So, until the rest of the indexing is fixed, it's probably best > to keep mod_perl2 out of the index entirely, since Stas wants to > play by his own rules and has trouble realizing the implications > of an altered @INC on a project-by-project basis. Ick. Ick. ick.
As Apache:: module authors begin to release new and incompatible modules that only work with mp2's "use Apache2" system, this will also happen to them, with the new versions also locked out of the indexer. This has ALREADY happened with prereleased modules such as Apache::Resource.
(Randy Kobes) > PAUSE is doing what it's supposed to do. I'm asking if > changing the Apache::Resource provider from mp1 to mp2 > is really what _we_ want to do, now that we know CPAN > will not support multi-versioning prior to mp2's release.
(Stas) > why not? Why mp1 should be favored above mp2? mp2 is here to stay, > mp1 is there to go. So if PAUSE doesn't want to index both, > it should be mp2, IMHO.
(Stas, in a different thread) > It's really a problem with other Apache modules like > Apache-Scoreboard, which can't be reached from anywhere but > CPAN. mod_perl-core was really just an example in that discussion. > The problem is much bigger than just one module (including other > modules which have nothing to do with modperl at all).
Unfortunately, because the problems that caused the "temporary" lock out will not go away, mod_perl2 and it's entire parallel plane of module will need to remain locked out of CPAN and will be unsupported by perldoc and all the perl tools indefinitely.
(Stas) > Besides, your suggestion to simply not index any similarly-named > mp1-modules, includes mod_perl.pm. So anybody who did moved to mp2 > and tries to check whether there is a new version by querying the > client for that module name will be mislead to think that there > are none. Or do you suggest to make a special case for > mod_perl.pm? > > And if you follow your own suggestion, you will have to completely > exclude libapreq2 from indexing, preventing anybody from seeing it > via CPAN clients. > > And to be consistent it will need to be followed by other > Apache:: modules, like Apache::Scoreboard. > > If you do all these, you can be sure that the migration to mp2 > will take a few years and more, since people will be simply unaware > of new things being released.
Perl 6 may provide some respite, but for perl 5 this means that EVERY install of mod_perl2 will need to be completely by hand, including all modules that are mp2-specific.
Summary: mod_perl2 may end up locked out of the CPAN indefinitely
--------------------------------------------------------------
At this point things are getting rather flamey and way too crazy, so I'm going to conclude this email for now.
I am CC'ing this email to a number of people I think may need to need to be brought in to this discussion, or that could be affected by this issue in a major way.
I am also CC'ing [EMAIL PROTECTED], which I believe is the address for the mod_perl management committee? If not, could someone from the committee please forward on.
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.
Others also appear to be taking this position as well.
(Joe Schaefer) > To be clear, I've been under the assumption that the mp2 > developers were/are assuming multi-version CPAN support was/is > going to happen. > > All I'm suggesting is that, now that we are reasonably certain > about CPAN's (lack of) functionality, that some reaffirmation of > the mp2 release plan takes place.
To the mod_perl users, thank you for your time, and please stay tuned. I hope that whatever is going to happen will be as quick and as painless for you guys as possible.
Adam Kennedy
-- 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
