The perlmodlib(1) manpage seems overly long + slightly garbled #13970
Comments
From naesten@gmail.comThis is a bug report for perl from naesten@gmail.com, I've noticed three problems with the permodlib(1) manpage: 1) It seems overly long, and without a unifying theme. I mean, first it's got some lists of module names, then an In fact, it is so long that when I look at it on perldoc.org, the Wouldn't it be better to split this into three pages? 2) The list of "Pragmatic Modules" also includes the names of many Flags: Site configuration information for perl 5.18.2: Configured by Debian Project at Sat Mar 1 14:00:24 UTC 2014. Summary of my perl5 (revision 5 version 18 subversion 2) configuration: Locally applied patches: @INC for perl 5.18.2: Environment for perl 5.18.2: |
From @jkeenanOn Fri Jul 04 20:28:13 2014, naesten@gmail.com wrote:
The disjointed nature of 'perlmodlib' stems in part from the fact that it is an auto-generated document. Humans write the descriptive material but the lists of pragmata and standard modules are inserted by pod/perlmodlib.PL upon installation. I think it is useful to have a list of the libraries associated with a particular version of the core distribution and having this list mechanically generated no doubt saves release managers lots of time. So far so good. But when it comes to a list of CPAN mirrors pod/perlmodlib.PL resorts to a hard-coded list mirrors. Since the Perl 5 Porters have no control whatsoever over mirrors, this information is almost certainly out-of-date as of the time it is released. And in this day and age the average Perl user rarely needs to think about which mirror she is getting her CPAN libraries from. IMO it would be better to provide the user with a one-line command that could query the current state of CPAN mirrors in much the same way that CPAN.pm, CPANPLUS and App::cpanminus do. Toolchain Gang: any suggestions? I did learn something new from this document, however! I never knew that 'perldoc perllocal' would give me a list of the non-core libraries I have installed on a particular machine. Lastly, with respect to the section called "Modules: Creation, Use, and Abuse": Over the years many similar documents have been written; we probably have some of them in the core distribution itself. However, anything "borrowed directly from Tim Bunce" is bound to be interesting, so I'm going to give this section a more careful reading.
This appears to have been addressed in Perl 5.20. Now, as to what action should be taken ... Based on past experience, I can safely say that the question of how to revise a man page which has been part of the Perl 5 core distribution for a long time is one on which: * *Many* people will have an opinion. * Forming a consensus on revisions will take time. * Once a consensus has formed, some *particular* person will have to take on the task of making revisions. * *Many* people will have an opinion on the proposed revisions. * Rinse. Repeat. In principle (or, at least, my opinion), this discussion should take place first on the Perl 5 Porters mailing list and only move into the bug tracking system when an actual draft of revisions is ready for comment. But since this has been filed as an RT ticket and since all RT tickets are copied to the P5P list/newsgroup, I recognize that the discussion will be recorded in RT in any case. In RT I am going to change the Status of this ticket to Stalled (which, pending reaching consensus, is where the issue lies). That should not prevent people from commenting on it on the list. Thank you very much. |
|
The RT System itself - Status changed from 'new' to 'open' |
|
@jkeenan - Status changed from 'open' to 'stalled' |
From @karenetheridgeOn Sun, Jul 06, 2014 at 06:57:03AM -0700, James E Keenan via RT wrote:
It doesn't -- iirc, only modules installed via ExtUtils::MakeMaker are |
|
The RT System itself - Status changed from 'stalled' to 'open' |
Migrated from rt.perl.org#122231 (status was 'open')
Searchable as RT122231$
The text was updated successfully, but these errors were encountered: