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.
