Project:Perl/dev-lang/perl

= 5.22.3_rc4 =


 * added to tree at
 * First :   at


 * Released to Gentoo early to get security issues resolved, but with  changes reverted.
 * Logically equivalent to upstreams  final.


 * See

Known Issues
= 5.22.3 =


 * Under consideration, but would be logically equivalent to + some cosmetic changes. Sadly, those cosmetic changes could cause needless complications in virtuals due to the virtuals for Module-CoreList being logically 5.22.3_rc4 < 5.24.1_rc4 < 5.22.3 < 5.22.4 Which means potential complications to work out there without benefit.

= 5.24.1_rc4 =


 * added to tree at


 * Released to Gentoo early to get security issues resolved, and to get  API breakage into testing.


 * Not equivalent to upstreams  final as upstream reverted   changes.


 * See

= 5.24.1 =
 * Pending: https://github.com/gentoo/gentoo/pull/3920
 * Newer
 * changes reverted upstream in  patched back in for testers ( See  )
 * With patching CPANPLUS fixed
 * With Zlib tests failing worked around by disabling tests

= 2016  fiasco =

Following CVE-2016-1238 ( Gentoo bug ), Perl upstream deployed a lot of patches to protect code from unintended side effects of accidentally including libraries from paths relative to.

Most of these took the form of limiting shipped scripts which had no inherent need for this behaviour, and could be safely removed without consequences to end users.

However, one change that was not strictly necessary, ( or mentioned in the CVE ), was the modification of a very commonly used module, who's implementation means that it is mostly a proxy for a core language feature that has been present ( and depended upon ) for the last 20 years.

Upstream saw it fit that they must break any and all user code that intentionally relied on this effect, while not actually fixing the underlying problem, Perl's  implementation, which is still subject to this risk, and will be until at least Perl 5.26.

And then upstream got stuck in a 6 month long conflict, while upstream tried to work out how to break this aspect of  while limiting the number of side effects that broke API, insistent that breaking API in a stable, bugfix point release was the way to proceed.

Meanwhile, the nature of the security hole was the internets worst kept secret, and all the identified and quantifiable risks were sitting there in the repo, fixed, but not distributed.

And 6 months on sitting on your hands when the CVE warrants a reaction in under a week is not good.

Subsequently,  was shipped to Gentoo, with   stripping out upstreams   changes so we could actually deploy the security fixes that mattered.

And  was shipped to Gentoo with   preserved, in  order to use it as a testing target to smoke out anything that broke.

Later, upstream came around, and themselves reverted the  changes so they could get the security release out.

As a side effect, this means that Gentoo's  was essentially upstreams , modulo some cosmetic changes

And there is subsequently no real need to ship a, though we could just to reduce confusion.

However,  should continue to ship as-is, with the "base.pm might break your tools" fixes, as upstream are tempted to replicate the same mistake in   ( and maybe   ), as shipping upstreams   would revert this change ( just like they did for   ), which would reduce our ability to test for this bug before we got around to stabilizing it.

In short
Don't read too much in the _rc suffix when it comes to tracking perl stuff, they're mostly used for tracking downstream-vs-upstream versions, and your impressions of stability should be based on Gentoo Keywording, not upstream versioning, as the Perl Project apparently care more about not breaking your stuff than upstream do.

is just as safe as