perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: [mp2] PAUSE indexer issues
Date Mon, 27 Dec 2004 17:40:06 GMT
On Mon, 27 Dec 2004, Stas Bekman wrote:

> Randy Kobes wrote:
[ ... ]
> > In a similar spirit to the provision of mp2doc as a
> > solution to the problem of using 'perldoc' under mp2,
> > I'm wondering (out loud) if it might hasten an overall
> > solution to tbe CPAN/CPANPLUS problem by addressing it
> > initially just within mp2 itself. That is, have PAUSE
> > ignore all mp2-specific modules (they will still be
> > browseable via, so that existing mp1
> > users won't be confused. Instead, provide within the
> > mp2 sources an 'mp2cpan/mp2cpanp' script as an interface
> > to the CPAN/CPANPLUS shells just for installing mp2-specific
> > modules (which could require to adjust @INC,
> > if present). There's a number of tools at hand one can use:
> > - Module::Install, for customizing installations;
> > - META.yml files, for distribution information, even
> > if PAUSE doesn't recognize all fields;
> > - the possibility to generate, and place on CPAN, a
> > $CPAN/authors/S/SO/SOMEID/04moduledata.gz file that has the
> > desired information on mp2 modules. If nothing else, this
> > could be used just to "overload" the current information
> > in the $CPAN/modules/ indices for mp2-specific things
> > (eg, associate Apache::Request with libapreq2, rather
> > than with libapreq as $CPAN/modules/ does).
> Randy, +1 to mp2cpan(?:p?).

sorry - mp2cpanp eq 'wrapper around CPANPLUS shell'

> But you miss an important bit. If we tell
> PAUSE to ignore mp2 modules, mp2cpan will be able to find them, and so
> it'll be useless.

I assume that to mean that if PAUSE ignores mp2 modules,
mp2cpan will be *unable* to find them ...

> BTW, mp2cpan is really:
> perl -MApache2 -MCPAN -eshell
> Moreover you're again concentrating on the mp2-core, whereas the problem
> is much bigger. Other Apache:: modules already suffer from the same issue,
> so applying a broken workaround for the core won't do anything good for
> the other modules out there.

I was thinking of something even more involved, as you're
right, there's more to this issue than the mp2-core.
Invoking the CPAN/CPANPLUS shell as
   perl -MApache2 -MCPAN -eshell
solves one problem - that of being able to now see installed
modules under an Apache2/ - but it doesn't address the issue
of the PAUSE indices either not seeing mp2 modules, if
they're not indexed, or else seeing the "wrong" versions, if
the mp1 modules are indexed instead. What I was thinking of
is something along the lines of what CPAN::Site does - add
another repository for CPAN modules. This requires
additional 02packages.details.txt.gz and 01mailrc.txt.gz
index files, except rather than pointing to a local site,
these would point to existing modules on CPAN that are
either not visible or are "wrongly indexed" (according to
the desired mod_perl version) in the standard PAUSE/CPAN

In one scenario, assume PAUSE doesn't index any mp2 modules
(either in the mp2 core or 3rd party, like
Apache-ScoreBoard-2.02 or Apache::Request of libapreq2).
Then, if an mp2 user invokes an mp2cpan, one could assume
she/he wants the mp2 versions, and the additional index
files would either provide mp2 modules missing from the
PAUSE indices (eg, Apache::RequestUtil), or else remap
existing mp1 modules (eg, Apache-ScoreBoard-0.10) to their
mp2 versions.

Of course, one wouldn't want to maintain these additional
index files manually, especially for 3rd party modules. One
trigger that perhaps could be used to automatically add
packages to the indices is if, in their META.yml file, they
used a prerequisite of, indicating they're a pure
mp2 package.

These are just some thoughts - I certainly don't want
to detract from a long-term, scaleable solution. But
perhaps something along these lines might be workable?

best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message