to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
Upstream changes:
version 0.003; 2010-04-10
* bugfix: in pure-Perl implementation, make sure ambient package (from
which require is invoked) is passed on correctly to the code in the
required file, on those Perls where it is so inherited
* in XS, use macros to avoid explicit passing of aTHX, in the manner
of the core
* in XS, avoid using "class" as a variable name, for compatibility
with C++ compilers
* make all numeric comparisons against $] stringify it first, to avoid
architecture-dependent problems with floating point rounding giving
it an unexpected numeric value
* in Build.PL, explicitly declare configure-time requirements
* add MYMETA.yml to .cvsignore
There is a bug in Perl's handling of the %^H (lexical hints) variable that
causes lexical state in one file to leak into another that is required/used
from it. This bug will probably be fixed in Perl 5.10.2, and is definitely
fixed in Perl 5.11.0, but in any earlier version it is necessary to work
around it. On versions of Perl that require a fix, this module globally
changes the behaviour of require and use so that they no longer exhibit the
bug. This is the most convenient kind of workaround, and is meant to be
invoked by modules that make use of lexical state.
The workaround supplied by this module takes effect the first time its
import method is called. Typically this will be done by means of a use
statement. This should be done before putting anything into %^H that would
have a problem with leakage; usually it suffices to do this when loading
the module that supplies the mechanism to set up the vulnerable lexical
state. Invoking this module multiple times, from multiple lexical-related
modules, is not a problem: the workaround is only applied once, and applies
to everything.
