Log message:
Bump for perl-5.20.0.
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.

Log message:
Changes 2.19:
** Improvements

  Performance has improved, typically by 10% and in some cases by a
  factor of 200.  However, performance of grep -P in UTF-8 locales has
  gotten worse as part of the fix for the crashes mentioned below.

** Bug fixes

  grep no longer mishandles patterns like [a-[.z.]], and no longer
  mishandles patterns like [^a] in locales that have multicharacter
  collating sequences so that [^a] can match a string of two characters.

  grep no longer mishandles an empty pattern at the end of a pattern list.
  [bug introduced in grep-2.5]

  grep -C NUM now outputs separators consistently even when NUM is zero,
  and similarly for grep -A NUM and grep -B NUM.
  [bug present since "the beginning"]

  grep -f no longer mishandles patterns containing NUL bytes.
  [bug introduced in grep-2.11]

  Plain grep, grep -E, and grep -F now treat encoding errors in patterns
  the same way the GNU regular expression matcher treats them, with respect
  to whether the errors can match parts of multibyte characters in data.
  [bug present since "the beginning"]

  grep -w no longer mishandles a potential match adjacent to a letter that
  takes up two or more bytes in a multibyte encoding.
  Similarly, the patterns '\<', '\>', '\b', and '\B' no longer
  mishandle word-boundary matches in multibyte locales.
  [bug present since "the beginning"]

  grep -P now reports an error and exits when given invalid UTF-8 data.
  Previously it was unreliable, and sometimes crashed or looped.
  [bug introduced in grep-2.16]

  grep -P now works with -w and -x and backreferences. Before,
  echo aa|grep -Pw '(.)\1' would fail to match, yet
  echo aa|grep -Pw '(.)\2' would match.

  grep -Pw now works like grep -w in that the matched string has to be
  preceded and followed by non-word components or the beginning and end
  of the line (as opposed to word boundaries before).  Before, this
  echo a@@a| grep -Pw @@ would match, yet this
  echo a@@a| grep -w @@ would not.  Now, they both fail to match,
  per the documentation on how grep's -w works.

  grep -i no longer mishandles patterns containing titlecase characters.
  For example, in a locale containing the titlecase character
  'Lj' (U+01C8 LATIN CAPITAL LETTER L WITH SMALL LETTER J),
  'grep -i Lj' now matches both 'LJ' (U+01C7 LATIN CAPITAL LETTER LJ)
  and 'lj' (U+01C9 LATIN SMALL LETTER LJ).

Log message:
Changes 2.18:
Bug fixes:
* grep no longer mishandles patterns like [^^-~] in unibyte locales.
* grep -i in a multibyte, non-UTF8 locale could be up to 200 times slower
    than in 2.16.

Log message:
Changes 2.16:

** Bug fixes

  Fix gnulib-provided maint.mk so that the release procedure described
  in README-release actually does what we want.  Before that fix, that
  procedure resulted in a grep-2.15 tarball that would lead to a grep
  binary whose --version-reported version number was 2.14.51...

  The fix to make \s and \S work with multi-byte white space broke
  the use of each shortcut whenever followed by a repetition operator.
  For example, \s*, \s+, \s? and \s{3} would all malfunction in a
  multi-byte locale.  [bug introduced in grep-2.15]

  The fix to make grep -P work better with UTF-8 made it possible for
  grep to evoke a larger set of PCRE errors, some of which could trigger
  an abort.  E.g., this would abort:
    printf '\x82'|LC_ALL=en_US.UTF-8 grep -P y
  Now grep handles arbitrary PCRE errors.  [bug introduced in grep-2.15]

  Handle very long lines (2GiB and longer) on systems with a deficient
  read system call.

Log message:
Update to 2.15:

* Noteworthy changes in release 2.15 (2013-10-26) [stable]

** Bug fixes

  grep's \s and \S failed to work with multi-byte white space characters.
  For example, \s would fail to match a non-breaking space, and this
  would print nothing: printf '\xc2\xa0' | LC_ALL=en_US.UTF-8 grep '\s'
  A related bug is that \S would mistakenly match an invalid multibyte
  character.  For example, the following would match:
    printf '\x82\n' | LC_ALL=en_US.UTF-8 grep '^\S$'
  [bug present since grep-2.6]

  grep -i would segfault on systems using UTF-16-based wchar_t (Cygwin)
  when converting an input string containing certain 4-byte UTF-8
  sequences to lower case.  The conversions to wchar_t and back to
  a UTF-8 multibyte string did not take surrogate pairs into account.
  [bug present since at least grep-2.6, though the segfault is new with 2.13]

  grep -E would segfault when given a regexp like '([^.]*[M]){1,2}'
  for any multibyte character M. [bug introduced in grep-2.6, which would
  segfault, but 2.7 and 2.8 had no problem, and 2.9 through 2.14 would
  hit a failed assertion. ]

  grep -F would get stuck in an infinite loop when given a search string
  that is an invalid byte sequence in the current locale and that matches
  the bytes of the input twice on a line.  Now grep fails with exit status 1.

  grep -P could misbehave.  While multi-byte mode is only supported by PCRE
  with UTF-8 locales, grep did not activate it.  This would cause failures
  to match multibyte characters against some regular expressions, especially
  those including the '.' or '\p' metacharacters.

** New features

  grep -P can now use a just-in-time compiler to greatly speed up matches,
  This feature is transparent to the user; no flag is required to enable
  it.  It is only available if the corresponding support in the PCRE
  library is detected when grep is compiled.

Log message:
Bump all packages for perl-5.18, that
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package

Like last time, where this caused no complaints.

Log message:
Mention that this also licensed under later versions as 3 of the GNU GPL.
Pointed out by Snader_LB.

Log message:
Add PKGGNUDIR support.

Log message:
Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.

Log message:
Bump all packages that use perl, or depend on a p5-* package, or
are called p5-*.

I hope that's all of them.