libdbd-sqlite3-perl 1.33-1 source package in Ubuntu

Changelog

libdbd-sqlite3-perl (1.33-1) unstable; urgency=low

  [ Maximilian Gass ]
  * New upstream release
  * Remove skip_fts3.patch, applied upstream
  * Bump Standards-Version to 3.9.2: no changes necessary
  * Delete SQLite source after install, not during cleanup (prevent
    accidental commit of deletion)

  [ gregor herrmann ]
  * Update upstream copyright holders and years of copyright.
 -- Ubuntu Archive Auto-Sync <email address hidden>   Sun,  12 Jun 2011 12:47:18 +0000

Upload details

Uploaded by:
Ubuntu Archive Auto-Sync
Uploaded to:
Oneiric
Original maintainer:
Debian Perl Group
Architectures:
any
Section:
perl
Urgency:
Low Urgency

See full publishing history Publishing

Series Pocket Published Component Section

Downloads

File Size SHA-256 Checksum
libdbd-sqlite3-perl_1.33.orig.tar.gz 1.3 MiB e0b2fbf88d7d8aa13aa8b7c4a6cbe4f10eb92df30138e4201c4c64f883a958de
libdbd-sqlite3-perl_1.33-1.debian.tar.gz 8.5 KiB 6cfa30ad3a19a61888dd31a8272e3c3374abb298569a25e2c3d23f778c6260cb
libdbd-sqlite3-perl_1.33-1.dsc 2.2 KiB 29fd1fb9b0a7a6a7b2bc6ed662d82bdc600248a6a4c1c4fc8714d38c229b34e9

Available diffs

View changes file

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.