libdbd-sqlite3-perl 1.40-3 source package in Ubuntu

Changelog

libdbd-sqlite3-perl (1.40-3) unstable; urgency=medium


  * Add 0001-error-messages-have-been-slightly-changed-since-3.8..patch patch.
    Fixes "FTBFS: test failures: UNIQUE constraint failed".
    Thanks to Dominic Hargreaves <email address hidden> (Closes: #735022)
  * Declare compliance with Debian policy 3.9.5
  * Update versioned Build-Depends on debhelper to (>= 9.20120312~)

 -- Salvatore Bonaccorso <email address hidden>  Sun, 12 Jan 2014 13:15:15 +0100

Upload details

Uploaded by:
Debian Perl Group
Uploaded to:
Sid
Original maintainer:
Debian Perl Group
Architectures:
any
Section:
perl
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Trusty release main perl

Downloads

File Size SHA-256 Checksum
libdbd-sqlite3-perl_1.40-3.dsc 2.3 KiB c228d8b4c92bb6e672ebacc4c4a795fdbdcb4743a6cc7243c8d42d7783e9436b
libdbd-sqlite3-perl_1.40.orig.tar.gz 1.5 MiB 21fb65e740b6265512c82232b4ad8f75c19ac84c216830112656274eb8e375fb
libdbd-sqlite3-perl_1.40-3.debian.tar.gz 11.0 KiB 5031f85dbdad86a6b0856355e109525dcff2300d9cb8342f6277ecd0c4f167fe

Available diffs

No changes file available.

Binary packages built by this source

libdbd-sqlite3-perl: Perl DBI driver with a self-contained RDBMS

 DBD::SQLite is a Perl DBI driver with a self-contained relational database
 management system. It embeds a small and fast embedded SQL database engine
 called SQLite (see sqlite3) into a DBI driver. It is useful if you want a
 relational database for your project, but don't want to install a large
 RDBMS system like MySQL or PostgreSQL.
 .
 SQLite supports the following features:
 .
  * Implements a large subset of SQL92 (<URL:http://www.sqlite.org/lang.html>)
  * A complete DB in a single disk file
    Everything for your database is stored in a single disk file, making it
    easier to move things around than with DBD::CSV.
  * Atomic commit and rollback
 .
 The engine is very fast, but for updates/inserts/dml it does perform a global
 lock on the entire database. This, obviously, might not be good for multiple
 user systems. The database also appears to be significantly faster if your
 transactions are coarse.