On Sun, 26 Dec 2004, Stas Bekman wrote:
The current state of things is as follows: we release things as they are, and it's up to users to request/demand to have PAUSE and CPAN clients fixed.
But how many users will be aware, or even suspect, that the
root of the issue is something so fundamental?
We ought to well document that and point users to where they should send their frustration emails (p5p, as I don't know any other place PAUSE/CPAN can be discussed).
They may think their own CPAN/CPANPLUS installation is at fault (which is not unheard of with tools as complex as these). Or they may feel it a misconfiguration of the module they're trying to install. Rather than being driven to complain, this may drive them away ...
I doubt that a broken CPAN client will drive users away. It's more likely that people will stop using the CPAN client altogether.
It seems apparent from the recent discussions that there's no strong consensus on how to address this problem. Even if there was, though, I imagine the implementation, and subsequent propagation of new tools, would take time - allowing multiple module versions is a major change, and doing so in such a way so as to not break existing CPAN-related tools would be tricky. And there's also the question of efficiency - right now the CPAN.pm shell on my system uses about 40 MB of memory when loaded, and that's just with the latest module/distribution versions.
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?). 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.
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.
Of course, all this may be more trouble than it's worth, and as Stas emphasizes, such workarounds may actually be counter-productive. But if putting together a workable solution along this, or some other, line is possible outside of the standard PAUSE channels, integrating it at a later point within PAUSE may be easier to accomplish. And it may also make the transition to mp2 more transparent and easier for the average user ...
The problem is that I for one can't see such a workable solution. I've happened to see a lot of proposals in the last year or so, none of them was workable, they were all solving one problem, but creating another. We have spent multiple hours discussing this here, at the users list, and p5p to no avail. Of course that doesn't mean that there is absolutely no other solution, but I haven't heard of one such yet.
I think if people have stopped looking for workarounds right now and started working on the PAUSE/CPAN fixes, it won't take too long before the problem is fixed. Meanwhile all those neverending discussings do nothing to make the solution come sooner, but the opposite.
-- __________________________________________________________________ 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]
