This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Re-fold long lines in INSTALL
authorH.Merijn Brand <h.m.brand@xs4all.nl>
Sat, 7 Mar 2015 10:45:53 +0000 (11:45 +0100)
committerH.Merijn Brand <h.m.brand@xs4all.nl>
Sat, 7 Mar 2015 10:45:53 +0000 (11:45 +0100)
I used a guide-width of 73

INSTALL

diff --git a/INSTALL b/INSTALL
index 164725e..78441d8 100644 (file)
--- a/INSTALL
+++ b/INSTALL
@@ -89,8 +89,8 @@ potential incompatibilities introduced with this release.  A few of
 the most important issues are listed below, but you should refer
 to pod/perldelta.pod for more detailed information.
 
-B<WARNING:> This version is not binary compatible with earlier versions of Perl.
-If you have built extensions (i.e. modules that include C code)
+B<WARNING:> This version is not binary compatible with earlier versions
+of Perl.  If you have built extensions (i.e. modules that include C code)
 using an earlier version of Perl, you will need to rebuild and reinstall
 those extensions.
 
@@ -250,15 +250,15 @@ enable this, run
 
 The default is to compile without thread support.
 
-Perl used to have two different internal threads implementations.  The current
-model (available internally since 5.6, and as a user-level module since 5.8) is
-called interpreter-based implementation (ithreads), with one interpreter per
-thread, and explicit sharing of data.  The (deprecated) 5.005 version
-(5005threads) was removed for release 5.10.
+Perl used to have two different internal threads implementations.  The
+current model (available internally since 5.6, and as a user-level module
+since 5.8) is called interpreter-based implementation (ithreads), with
+one interpreter per thread, and explicit sharing of data. The (deprecated)
+5.005 version (5005threads) was removed for release 5.10.
 
 The 'threads' module is for use with the ithreads implementation.  The
-'Thread' module emulates the old 5005threads interface on top of the current
-ithreads model.
+'Thread' module emulates the old 5005threads interface on top of the
+current ithreads model.
 
 When using threads, perl uses a dynamically-sized buffer for some of
 the thread-safe library calls, such as those in the getpw*() family.
@@ -275,8 +275,8 @@ Since Perl 5.6.0, Perl has supported large files (files larger than
 support is on by default.
 
 This is both good and bad. It is good in that you can use large files,
-seek(), stat(), and -s them.  It is bad in that if you are interfacing Perl
-using some extension, the components you are connecting to must also
+seek(), stat(), and -s them.  It is bad in that if you are interfacing
+Perl using some extension, the components you are connecting to must also
 be large file aware: if Perl thinks files can be large but the other
 parts of the software puzzle do not understand the concept, bad things
 will happen.
@@ -422,9 +422,9 @@ between different runs of Perl, since Data::Dumper by default dumps
 hashes "unordered".  The use of the Data::Dumper C<Sortkeys> option is
 recommended.
 
-See L<perlrun/PERL_HASH_SEED> and L<perlrun/PERL_PERTURB_KEYS> for details on
-the environment variables, and L<perlsec/Algorithmic Complexity Attacks> for
-further security details.
+See L<perlrun/PERL_HASH_SEED> and L<perlrun/PERL_PERTURB_KEYS> for
+details on the environment variables, and L<perlsec/Algorithmic
+Complexity Attacks> for further security details.
 
 =head3 SOCKS
 
@@ -546,17 +546,18 @@ point to your new architecture-dependent library.
 
 =head3 Environment access
 
-Perl often needs to write to the program's environment, such as when C<%ENV>
-is assigned to. Many implementations of the C library function C<putenv()>
-leak memory, so where possible perl will manipulate the environment directly
-to avoid these leaks. The default is now to perform direct manipulation
-whenever perl is running as a stand alone interpreter, and to call the safe
-but potentially leaky C<putenv()> function when the perl interpreter is
-embedded in another application. You can force perl to always use C<putenv()>
-by compiling with C<-Accflags="-DPERL_USE_SAFE_PUTENV">, see section
-L</"Altering Configure variables for C compiler switches etc.">.
-You can force an embedded perl to use direct manipulation by setting
-C<PL_use_safe_putenv = 0;> after the C<perl_construct()> call.
+Perl often needs to write to the program's environment, such as when
+C<%ENV> is assigned to. Many implementations of the C library function
+C<putenv()> leak memory, so where possible perl will manipulate the
+environment directly to avoid these leaks. The default is now to perform
+direct manipulation whenever perl is running as a stand alone interpreter,
+and to call the safe but potentially leaky C<putenv()> function when the
+perl interpreter is embedded in another application. You can force perl
+to always use C<putenv()> by compiling with
+C<-Accflags="-DPERL_USE_SAFE_PUTENV">, see section L</"Altering Configure
+variables for C compiler switches etc.">.  You can force an embedded perl
+to use direct manipulation by setting C<PL_use_safe_putenv = 0;> after
+the C<perl_construct()> call.
 
 =head2 Installation Directories
 
@@ -600,10 +601,11 @@ variables are in the file Porting/Glossary.
     $html1direxp       (none)
     $html3direxp       (none)
 
-$prefixexp is generated from $prefix, with ~ expansion done to convert home
-directories into absolute paths. Similarly for the other variables listed. As
-file system calls do not do this, you should always reference the ...exp
-variables, to support users who build perl in their home directory.
+$prefixexp is generated from $prefix, with ~ expansion done to convert
+home directories into absolute paths. Similarly for the other variables
+listed. As file system calls do not do this, you should always reference
+the ...exp variables, to support users who build perl in their home
+directory.
 
 Actually, Configure recognizes the SVR3-style
 /usr/local/man/l_man/man1 directories, if present, and uses those
@@ -691,10 +693,10 @@ the /usr/local hierarchy.
 
 The entire installed library hierarchy is installed in locations with
 version numbers, keeping the installations of different versions distinct.
-However, later installations of Perl can still be configured to search the
-installed libraries corresponding to compatible earlier versions.
-See L<"Coexistence with earlier versions of perl 5"> below for more details
-on how Perl can be made to search older version directories.
+However, later installations of Perl can still be configured to search
+the installed libraries corresponding to compatible earlier versions.
+See L<"Coexistence with earlier versions of perl 5"> below for more
+details on how Perl can be made to search older version directories.
 
 Of course you may use these directories however you see fit.  For
 example, you may wish to use $siteprefix for site-specific files that
@@ -888,15 +890,15 @@ and these will be used as locations to search for modules by the perl
 being built. The list of perl versions found will be put in the Configure
 variable inc_version_list.
 
-To disable this use of older perl modules, even completely valid pure perl
-modules, you can specify to not include the paths found:
+To disable this use of older perl modules, even completely valid pure
+perl modules, you can specify to not include the paths found:
 
        sh Configure -Dinc_version_list=none ...
 
-If you do want to use modules from some previous perl versions, the variable
-must contain a space separated list of directories under the site_perl
-directory, and has to include architecture-dependent directories separately,
-eg.
+If you do want to use modules from some previous perl versions, the
+variable must contain a space separated list of directories under the
+site_perl directory, and has to include architecture-dependent
+directories separately, eg.
 
        sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...
 
@@ -985,8 +987,8 @@ much, much more slowly than a standard perl.
 =head2 DTrace support
 
 On platforms where DTrace is available, it may be enabled by
-using the -Dusedtrace option to Configure. DTrace probes are available for
-subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a
+using the -Dusedtrace option to Configure. DTrace probes are available
+for subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a
 simple D script that uses them:
 
   perl$target:::sub-entry, perl$target:::sub-return {
@@ -1081,12 +1083,12 @@ you have gdbm installed in any of (/usr/local, /opt/local, /usr/gnu,
 The version of BerkeleyDB distributed by Oracle installs in a
 version-specific directory by default, typically something like
 /usr/local/BerkeleyDB.4.7.  To have Configure find that, you need to add
--I/usr/local/BerkeleyDB.4.7/include to cc flags, as in the previous example,
-and you will also have to take extra steps to help Configure find -ldb.
-Specifically, when Configure prompts you for library directories,
-add /usr/local/BerkeleyDB.4.7/lib to the list.  Also, you will need to
-add appropriate linker flags to tell the runtime linker where to find the
-BerkeleyDB shared libraries.
+-I/usr/local/BerkeleyDB.4.7/include to cc flags, as in the previous
+example, and you will also have to take extra steps to help Configure
+find -ldb.  Specifically, when Configure prompts you for library
+directories, add /usr/local/BerkeleyDB.4.7/lib to the list.  Also, you
+will need to add appropriate linker flags to tell the runtime linker
+where to find the BerkeleyDB shared libraries.
 
 It is possible to specify this from the command line (all on one
 line):
@@ -1114,10 +1116,11 @@ system.
 
 If you are cross-compiling, or are using a compiler which has it's own
 headers and libraries in a nonstandard location, and your compiler
-understands the C<--sysroot> option, you can use the C<-Dsysroot> option to
-specify the logical root directory under which all libraries and headers
-are searched for. This patch adjusts Configure to search under $sysroot, instead of /.
-    
+understands the C<--sysroot> option, you can use the C<-Dsysroot> option
+to specify the logical root directory under which all libraries and
+headers are searched for. This patch adjusts Configure to search under
+$sysroot, instead of /.
+
 --sysroot is added to ccflags and friends so that make in
 ExtUtils::MakeMaker, and other extensions, will use it.
 
@@ -1247,10 +1250,10 @@ resources that are generously available on most platforms.
 
 =item o
 
-How best to optimize for the platform, both in terms of binary size and/or
-speed, and for Perl feature support. Because of wide variations in the
-implementation of shared libraries and of threading, for example, Configure
-often needs hints in order to be able to use these features.
+How best to optimize for the platform, both in terms of binary size
+and/or speed, and for Perl feature support. Because of wide variations in
+the implementation of shared libraries and of threading, for example,
+Configure often needs hints in order to be able to use these features.
 
 =back
 
@@ -1260,20 +1263,21 @@ will offer to use that hint file. Unless you have a very good reason
 not to, you should accept its offer.
 
 Several of the hint files contain additional important information.
-If you have any problems, it is a good idea to read the relevant hint file
-for further information.  See hints/solaris_2.sh for an extensive example.
-More information about writing good hints is in the hints/README.hints
-file, which also explains hint files known as callback-units.
+If you have any problems, it is a good idea to read the relevant hint
+file for further information.  See hints/solaris_2.sh for an extensive
+example.  More information about writing good hints is in the
+hints/README.hints file, which also explains hint files known as
+callback-units.
 
 Note that any hint file is read before any Policy file, meaning that
 Policy overrides hints -- see L</Site-wide Policy settings>.
 
 =item WHOA THERE!!!
 
-If you are re-using an old config.sh, it's possible that Configure detects
-different values from the ones specified in this file.  You will almost
-always want to keep the previous value, unless you have changed something
-on your system.
+If you are re-using an old config.sh, it's possible that Configure
+detects different values from the ones specified in this file.  You will
+almost always want to keep the previous value, unless you have changed
+something on your system.
 
 For example, suppose you have added libgdbm.a to your system
 and you decide to reconfigure perl to use GDBM_File.  When you run
@@ -1343,8 +1347,8 @@ and add a line for toke.c ahead of the catch-all *) so that it now reads:
     toke) optimize='-g' ;;
     *) ;;
 
-You should not edit the generated file cflags directly, as your changes will
-be lost the next time you run Configure, or if you edit config.sh.
+You should not edit the generated file cflags directly, as your changes
+will be lost the next time you run Configure, or if you edit config.sh.
 
 To explore various ways of changing ccflags from within a hint file,
 see the file hints/README.hints.
@@ -1391,8 +1395,8 @@ command line parameter to Configure, for example like this:
 
 or answer first 'y' to the question 'Install any extra modules?' and
 then answer "Bundle::LWP DBI" to the 'Extras?' question.
-The module or the bundle names are as for the CPAN module 'install' command.
-This will only work if those modules are to be built as dynamic
+The module or the bundle names are as for the CPAN module 'install'
+command.  This will only work if those modules are to be built as dynamic
 extensions.  If you wish to include those extra modules as static
 extensions, see L<"Extensions"> above.
 
@@ -1402,8 +1406,8 @@ or via a local copy such as a CD-ROM or a local CPAN mirror.  If you
 do not, using the extra modules option will die horribly.
 
 Also notice that you yourself are responsible for satisfying any extra
-dependencies such as external headers or libraries BEFORE trying the build.
-For example: you will need to have the Foo database specific
+dependencies such as external headers or libraries BEFORE trying the
+build.  For example: you will need to have the Foo database specific
 headers and libraries installed for the DBD::Foo module.  The Configure
 process or the Perl build process will not help you with these.
 
@@ -1467,8 +1471,9 @@ If you have any locale-related environment variables set, try unsetting
 them.  I have some reports that some versions of IRIX hang while
 running B<./miniperl configpm> with locales other than the C locale.
 See the discussion under L<"make test"> below about locales and the
-whole L<perllocale/"LOCALE PROBLEMS"> section in the file pod/perllocale.pod.
-The latter is especially useful if you see something like this
+whole L<perllocale/"LOCALE PROBLEMS"> section in the file
+pod/perllocale.pod.  The latter is especially useful if you see something
+like this
 
        perl: warning: Setting locale failed.
        perl: warning: Please check that your locale settings:
@@ -1570,21 +1575,21 @@ installed.  It installs a /usr/local/include/arpa/inet.h that refers to
 these symbols.  Versions of BIND later than 8.1 do not install inet.h
 in that location and avoid the errors.  You should probably update to a
 newer version of BIND (and remove the files the old one left behind).
-If you can't, you can either link with the updated resolver library provided
-with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the Perl build and
-test process to avoid the problem.
+If you can't, you can either link with the updated resolver library
+provided with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the
+Perl build and test process to avoid the problem.
 
 =item .*_r() prototype NOT found
 
 On a related note, if you see a bunch of complaints like the above about
-reentrant functions -- specifically networking-related ones -- being present
-but without prototypes available, check to see if BIND 8.1 (or possibly
-other BIND 8 versions) is (or has been) installed. They install
-header files such as netdb.h into places such as /usr/local/include (or into
-another directory as specified at build/install time), at least optionally.
-Remove them or put them in someplace that isn't in the C preprocessor's
-header file include search path (determined by -I options plus defaults,
-normally /usr/include).
+reentrant functions -- specifically networking-related ones -- being
+present but without prototypes available, check to see if BIND 8.1 (or
+possibly other BIND 8 versions) is (or has been) installed. They install
+header files such as netdb.h into places such as /usr/local/include (or
+into another directory as specified at build/install time), at least
+optionally.  Remove them or put them in someplace that isn't in the C
+preprocessor's header file include search path (determined by -I options
+plus defaults, normally /usr/include).
 
 =item #error "No DATAMODEL_NATIVE specified"
 
@@ -1658,8 +1663,8 @@ for likely suspects.
 Some compilers will not compile or optimize the larger files (such as
 toke.c) without some extra switches to use larger jump offsets or
 allocate larger internal tables.  You can customize the switches for
-each file in cflags.SH.  It's okay to insert rules for specific files into
-makefile since a default rule only takes effect in the absence of a
+each file in cflags.SH.  It's okay to insert rules for specific files
+into makefile since a default rule only takes effect in the absence of a
 specific rule.
 
 =item Missing dbmclose
@@ -1727,8 +1732,8 @@ bval settings.  Upgrade your DB library or OS.
 
 =item Bad arg length for semctl, is XX, should be ZZZ
 
-If you get this error message from the ext/IPC/SysV/t/sem test, your System
-V IPC may be broken.  The XX typically is 20, and that is what ZZZ
+If you get this error message from the ext/IPC/SysV/t/sem test, your
+System V IPC may be broken.  The XX typically is 20, and that is what ZZZ
 also should be.  Consider upgrading your OS, or reconfiguring your OS
 to include the System V semaphores.
 
@@ -1801,7 +1806,8 @@ January 2014, these include Android, Blackberry 10, PocketPC aka
 WinCE, ARM Linux, and Solaris.  Previous versions of
 Perl also provided support for Open Zaurus, Symbian, and
 the IBM OS/400, but it's unknown if those ports are still functional.
-These platforms are known as the B<target> platforms, while the systems where the compilation takes place are the B<host> platforms.
+These platforms are known as the B<target> platforms, while the systems
+where the compilation takes place are the B<host> platforms.
 
 What makes the situation difficult is that first of all,
 cross-compilation environments vary significantly in how they are set
@@ -1822,7 +1828,8 @@ L<README.ce or perlce|perlce>
 
 =item Android
 
-L<"Cross-compilation" in README.android or perlandroid|perlandroid/Cross-compilation>
+L<"Cross-compilation" in README.android or
+perlandroid|perlandroid/Cross-compilation>
 
 =item Blackberry
 
@@ -1830,7 +1837,8 @@ L<"Cross-compilation" in README.qnx or perlqnx|perlqnx/Cross-compilation>
 
 =item Solaris
 
-L<"CROSS-COMPILATION" in README.solaris or perlsolaris|perlsolaris/CROSS-COMPILATION>
+L<"CROSS-COMPILATION" in README.solaris or
+perlsolaris|perlsolaris/CROSS-COMPILATION>
 
 =item Linux
 
@@ -1850,16 +1858,16 @@ C<-Dinstallprefix=...> might be handy, see L<Changing the installation
 directory>.
 
 About the cross-compilation support of Configure: There's two forms.
-The more common one requires some way of transferring and running executables
-in the target system, such as an ssh connection; this is the
-C<./Configure -Dusecrosscompile -Dtargethost=...> route.  The second method
-doesn't need access to the target system, but requires you to provide 
-a config.sh, and and a canned Makefile; the rest of this section describes
-the former.
+The more common one requires some way of transferring and running
+executables in the target system, such as an ssh connection; this is the
+C<./Configure -Dusecrosscompile -Dtargethost=...> route.  The second
+method doesn't need access to the target system, but requires you to
+provide a config.sh, and and a canned Makefile; the rest of this section
+describes the former.
 
 This cross-compilation setup of Configure has successfully been used in
-a wide variety of setups, such as a 64-bit OS X host for an Android ARM target, or
-an amd64 Linux host targeting x86 Solaris, or even Windows.
+a wide variety of setups, such as a 64-bit OS X host for an Android ARM
+target, or an amd64 Linux host targeting x86 Solaris, or even Windows.
 
 To run Configure in cross-compilation mode the basic switch that
 has to be used is C<-Dusecrosscompile>:
@@ -1891,7 +1899,8 @@ You can also specify a username to use for ssh/rsh logins
     -Dtargetuser=luser
 
 but in case you don't, "root" will be used.  Similarly, you can specify
-a non-standard (i.e. not 22) port for the connection, if applicable, through
+a non-standard (i.e. not 22) port for the connection, if applicable,
+through
 
     -Dtargetport=2222
 
@@ -1902,9 +1911,10 @@ chosen to be CPU-OS-ar and so on.
 (The C<ld> requires more thought and will be chosen later by Configure
 as appropriate).  This will also aid in guessing the proper
 operating system name for the target, which has other repercussions, like
-better defaults and possibly critical fixes for the platform.  If Configure
-isn't guessing the OS name properly, you may need to either add a hint file
-redirecting Configure's guess, or modify Configure to make the correct choice.
+better defaults and possibly critical fixes for the platform.  If
+Configure isn't guessing the OS name properly, you may need to either add
+a hint file redirecting Configure's guess, or modify Configure to make
+the correct choice.
 
 If your compiler doesn't follow that convention, you will also need to
 specify which target environment to use, as well as C<ar> and friends:
@@ -1914,11 +1924,11 @@ specify which target environment to use, as well as C<ar> and friends:
     -Dar=...
 
 Additionally, a cross-compilation toolchain will usually install it's own
-logical system root somewhere -- that is, it'll create a directory somewhere
-which includes subdirectories like 'include' or 'lib'.  For example, you
-may end up with C</skiff/local/arm-linux>, where 
+logical system root somewhere -- that is, it'll create a directory
+somewhere which includes subdirectories like 'include' or 'lib'.  For
+example, you may end up with C</skiff/local/arm-linux>, where
 C</skiff/local/arm-linux/bin> holds the binaries for cross-compilation,
-C</skiff/local/arm-linux/include> has the headers, and 
+C</skiff/local/arm-linux/include> has the headers, and
 C</skiff/local/arm-linux/lib> has the library files.
 If this is the case, and you are using a compiler that understands
 C<--sysroot>, like gcc or clang, you'll want to specify the
@@ -1972,16 +1982,16 @@ during 'make test'.  For example, if the target system has a nonstandard
 
     -Dtargetenv="export TMPDIR=/other/tmp;"
 
-If you are planning on cross-compiling to several platforms, or some other
-thing that would involve running Configure several times, there are two
-options that can be used to speed things up considerably.
+If you are planning on cross-compiling to several platforms, or some
+other thing that would involve running Configure several times, there are
+two options that can be used to speed things up considerably.
 As a bit of background, when you
 call Configure with C<-Dusecrosscompile>, it begins by actually partially
 building a miniperl on the host machine, as well as the generate_uudmap
 binary, and we end up using that during the build.
-So instead of building that new perl every single time, you can build it just
-once in a separate directory, and then pass the resulting binaries to
-Configure like this:
+So instead of building that new perl every single time, you can build it
+just once in a separate directory, and then pass the resulting binaries
+to Configure like this:
 
     -Dhostperl=/path/to/second/build/dir/miniperl
     -Dhostgenerate=/path/to/second/build/dir/generate_uudmap
@@ -2150,24 +2160,24 @@ about the various security aspects of temporary files.
 =back
 
 The core distribution can now run its regression tests in parallel on
-Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS> in
-your environment to the number of tests to run in parallel, and run
+Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS>
+in your environment to the number of tests to run in parallel, and run
 C<make test_harness>. On a Bourne-like shell, this can be done as
 
     TEST_JOBS=3 make test_harness  # Run 3 tests in parallel
 
-An environment variable is used, rather than parallel make itself, because
-L<TAP::Harness> needs to be able to schedule individual non-conflicting test
-scripts itself, and there is no standard interface to C<make> utilities to
-interact with their job schedulers.
+An environment variable is used, rather than parallel make itself,
+because L<TAP::Harness> needs to be able to schedule individual
+non-conflicting test scripts itself, and there is no standard interface
+to C<make> utilities to interact with their job schedulers.
 
 =head1 make install
 
 This will put perl into the public directory you specified to
-Configure; by default this is /usr/local/bin.  It will also try
-to put the man pages in a reasonable place.  It will not nroff the man
-pages, however.  You may need to be root to run B<make install>.  If you
-are not root, you must still have permission to install into the directories
+Configure; by default this is /usr/local/bin.  It will also try to put
+the man pages in a reasonable place.  It will not nroff the man pages,
+however.  You may need to be root to run B<make install>.  If you are not
+root, you must still have permission to install into the directories
 in question and you should ignore any messages about chown not working.
 
 If "make install" just says "'install' is up to date" or something
@@ -2188,8 +2198,8 @@ You can separately change the base used for versioned names (like
 
     make install PERLNAME=perl5 PERLNAME_VERBASE=perl
 
-This can be useful if you have to install perl as "perl5" (e.g. to
-avoid conflicts with an ancient version in /usr/bin supplied by your vendor).
+This can be useful if you have to install perl as "perl5" (e.g. to avoid
+conflicts with an ancient version in /usr/bin supplied by your vendor).
 Without this the versioned binary would be called "perl55.8.8".
 
 =head2 Installing perl under a different directory
@@ -2418,13 +2428,14 @@ read your message.  Your message will get relayed to over 400
 subscribers around the world so please try to keep it brief but clear.
 
 If the bug you are reporting has security implications, which make it
-inappropriate to send to a publicly archived mailing list, then please send
-it to perl5-security-report@perl.org. This points to a closed subscription
-unarchived mailing list, which includes all the core committers, who be able
-to help assess the impact of issues, figure out a resolution, and help
-co-ordinate the release of patches to mitigate or fix the problem across all
-platforms on which Perl is supported. Please only use this address for security
-issues in the Perl core, not for modules independently distributed on CPAN.
+inappropriate to send to a publicly archived mailing list, then please
+send it to perl5-security-report@perl.org. This points to a closed
+subscription unarchived mailing list, which includes all the core
+committers, who be able to help assess the impact of issues, figure out
+a resolution, and help co-ordinate the release of patches to mitigate or
+fix the problem across all platforms on which Perl is supported. Please
+only use this address for security issues in the Perl core, not for
+modules independently distributed on CPAN.
 
 If you are unsure what makes a good bug report please read "How to
 report Bugs Effectively" by Simon Tatham:
@@ -2435,10 +2446,11 @@ http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
 Perl 5.21.10 is not binary compatible with earlier versions of Perl.
 In other words, you will have to recompile your XS modules.
 
-In general, you can usually safely upgrade from one version of Perl (e.g.
-5.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without
+In general, you can usually safely upgrade from one version of Perl
+(e.g.  5.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without
 re-compiling all of your extensions.  You can also safely leave the old
-version around in case the new version causes you problems for some reason.
+version around in case the new version causes you problems for some
+reason.
 
 Usually, most extensions will probably not need to be recompiled to be
 used with a newer version of Perl.  Here is how it is supposed to work.
@@ -2570,9 +2582,10 @@ in Linux with perl-5.21.10 is as follows (under $Config{prefix}):
   ./lib/perl5/5.21.10/XSLoader.pm
   ./lib/perl5/5.21.10/i686-linux/auto/File/Glob/Glob.so
 
-Secondly, for perl-5.10.1, the Debian perl-base package contains 591 files,
-(of which 510 are for lib/unicore) totaling about 3.5MB in its i386 version.
-Omitting the lib/unicore/* files for brevity, the remaining files are:
+Secondly, for perl-5.10.1, the Debian perl-base package contains 591
+files, (of which 510 are for lib/unicore) totaling about 3.5MB in its
+i386 version.  Omitting the lib/unicore/* files for brevity, the
+remaining files are:
 
   /usr/bin/perl
   /usr/bin/perl5.10.1