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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
