perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Date Fri, 31 Dec 2004 19:27:56 GMT
(This email will also be posted to 
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.

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.



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

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.

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



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

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',
          './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):
 > 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

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
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" 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 websites (,,, 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 mailing list, which you may
wish to read at this point.

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,

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,, 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 or
 > 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 

 > 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 

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:
> 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
> % 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 (dev@?) 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 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 (
> 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 does this in order to implement API security, not to provide 
multiple "current" supported APIs.

But then again mod_perl2 has already forked the 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?

 > 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: 
 > Oct 2003: 
 > Dec 2003: 
 > Dec 2004: 
 > Amongst other proposed solutions, Autrijus has posted a concrete
 > solution to how to fix that: 

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 

(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
 > [*]- 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 

(Randal Schwartz)
 > ... modperl2 should remain de-listed from the CPAN until these
 > issues are resolved.  As long as the latest "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.

 > 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.

 > Besides, your suggestion to simply not index any similarly-named
 > mp1-modules, includes 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
 > 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, 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:
Mail list info:
List etiquette:

View raw message