perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] PAUSE indexer issues
Date Mon, 27 Dec 2004 22:52:04 GMT
Randy Kobes wrote:
> 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 search.cpan.org), 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 Apache2.pm 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'

I got it, I was just saying /mp2cpan(?:p?)/ instead of 'mp2cpan/mp2cpanp' :)

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

That's correct. It's first of all a PAUSE problem. Until PAUSE indexer is 
not fixed, we can't do any other fixes.

>>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
> indices.
> 
> 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 Apache2.pm, 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?

That's just silly. Manually creating and maintaining index files, because 
PAUSE doesn't do the right thing? And you lose the mirror system, unless 
you are going to release those indexes somewhere so they will be mirrored. 
  It'll probably take 2 minutes of coding for Andreas or Autrijus, who 
know the indexer code, to make this index autogenerated like all other 
indexes.
Really the simplest solution at the moment is what Jos was suggesting on 
p5p: index all versions and not just the latest and put them into a new 
index file, so not to confuse the old clients. Once this is done we can 
start talking about what to do with clients to make users happy.

In any case I'd rather see this workaround done for mp1 and not mp2. users 
are going to move to mp2, and it's better to have mp2 modules indexed and 
having mp1cpan as a workaround, since it will be eventually r.i.p.

Moreover, Geoff has raised an even move important issue on the users list. 
It's quite possible that 6 months from now we will have modperl 2.2 out, 
if Apache 2.2 comes with incompatible features. What you are going to do 
in that case? Write a workaround to a workaround? My apologies, but I 
think that any further search for yet another workaround is just a waste 
of time, and the spent energy is better redirected to solve real problems.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message