CVS log for pkgsrc/databases/p5-DBIx-Introspector/Makefile

Up to [cvs.NetBSD.org] / pkgsrc / databases / p5-DBIx-Introspector

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

*: recursive bump for perl 5.40

*: recursive bump for perl 5.38

Mass-change BUILD_DEPENDS to TOOL_DEPENDS outside mk/.

Almost all uses, if not all of them, are wrong, according to the
semantics of BUILD_DEPENDS (packages built for target available for
use _by_ tools at build-time) and TOOL_DEPEPNDS (packages built for
host available for use _as_ tools at build-time).

No change to BUILD_DEPENDS as used correctly inside buildlink3.

As proposed on tech-pkg:
https://mail-index.netbsd.org/tech-pkg/2023/06/03/msg027632.html

*: recursive bump for perl 5.36

*: recursive bump for perl 5.34

*: bump PKGREVISION for perl-5.32.

Bump PKGREVISIONs for perl 5.30.0

Update packages using a search.cpan.org HOMEPAGE to metacpan.org.

The former now redirects to the latter.

This covers the most simple cases where http://search.cpan.org/dist/name
can be changed to https://metacpan.org/release/name.

Reviewed by hand to hopefully make sure no unwanted changes sneak in.

Recursive bump for perl5-5.28.0

Recursive revbump from lang/perl5 5.26.0

Bump PKGREVISION for perl-5.24.

Update to 0.001005

Upstream changes:
0.001005  2015-01-29 17:47:49-06:00 America/Chicago
 - Fix error message for missing values (Thanks Wes Malone!)

Recursive PKGREVISION bump for all packages mentioning 'perl',
having a PKGNAME of p5-*, or depending such a package,
for perl-5.22.0.

Update 0.001003 to 0.001004
0.001004  2014-11-30 21:50:34-06:00 America/Chicago
 - Fix bug that disallowed false values

Import DBIx-Introspector-0.001003 as databases/p5-DBIx-Introspector.

DBIx::Introspector is a module factored out of the DBIx::Class
database detection code. Most code that needs to detect which
database it is connected to assumes that there is a one-to-one
mapping from database drivers to database engines. Unfortunately
reality is rarely that simple. For instance, DBD::ODBC is typically
used to connect to SQL Server, but ODBC can be used to connect
to PostgreSQL, MySQL, and Oracle. Additionally, while ODBC is the
most common way to connect to SQL Server, it is not the only option,
as DBD::ADO can also be used.