Problems found with existing distfiles:
distfiles/D6.data.ros.gz
distfiles/cstore0.2.tar.gz
distfiles/data4.tar.gz
distfiles/sphinx-2.2.7-release.tar.gz
No changes made to the cstore or mariadb55-client 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.
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.
Changes from previous:
1.43
- Segregated into different packages
- Removed code coverage from POD
- Fixed bug rt49537 Basic support for named parameters
- Fixed bug rt70421 Build.PL now contains Test::Exception
1.42
- Fixed bug rt66815 DBD::Mock::Session error clobbered
- Fixed bug rt69460 Info on META.yml is outdated
- Fixed bug rt69055 Spelling mistakes in POD
- RaiseError now works
* Changed incorrect verion number
Changes 1.40:
* Fixed bug rt44591 second preapre giving an error
* Fixed bug rt57981 warnings during clone
* Fixed bug rt63191 Synopsis errors
* Fixed bug rt66813 Google's group link in the POD
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!
Testing with databases can be tricky. If you are developing a system
married to a single database then you can make some assumptions
about your environment and ask the user to provide relevant connection
information. But if you need to test a framework that uses DBI,
particularly a framework that uses different types of persistence
schemes, then it may be more useful to simply verify what the
framework is trying to do -- ensure the right SQL is generated and
that the correct parameters are bound. DBD::Mock makes it easy to
just modify your configuration (presumably held outside your code)
and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql)
in your framework.
