Issues found with existing distfiles:
distfiles/eclipse-sourceBuild-srcIncluded-3.0.1.zip
distfiles/fortran-utils-1.1.tar.gz
distfiles/ivykis-0.39.tar.gz
distfiles/enum-1.11.tar.gz
distfiles/pvs-3.2-libraries.tgz
distfiles/pvs-3.2-linux.tgz
distfiles/pvs-3.2-solaris.tgz
distfiles/pvs-3.2-system.tgz
No changes made to these distinfo files.
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
--------------------
2.093 Thu Jun 26 2014
- fixed the test script to properly deal with sitecustomize and proxies
in all possible combinations (thanks a lot to Christan Walde (MITHALDU)
for his help with testing under Windows!)
2.092 Thu Apr 3 2014
- auto-dereferencing only works since 5.14
- move the xt/ tests back in t/, guarded by RELEASE_TESTING
2.091 Sat Mar 29 2014
- documentation fixes (thanks to Ioan Rogers (IOANR))
- test fixes (related to Module::CoreList)
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.
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.
from 2.05 to 2.06
pkgsrc changes:
2.06 Sun Jan 15 00:44:13 CET 2012
No code change, but:
- More thoroughly remove @INC from the error output
- do not open output test files as utf8
- fix a warning when using a dev version of Module::CoreList
Upstream changes:
2.03 Wed Sep 22 01:15:40 CEST 2010
- The 'hidecore' option will hide core modules in the output
(initial patch by David Leadbeater)
- moved author tests to xt/
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!
An apparently simple program may load a lot of modules. That's useful, but
sometimes it might be interesting to know exactly which part of a program
loads which module.
Devel::TraceUse can analyze a program to see which part used which module.
