copyright © 2004 sean finney <email@example.com>
this document is licensed under the Academic Free License, Version 2.1
this document is a technical reference for developers who are curious regarding how dbconfig-common works. before reading this document, it's highly recommended that you read the best practices for database applications draft, as the implementation design is based on rationale detailed in that document. if you are a developer looking to use dbconfig-common in your packages, you should read using dbconfig-common in debian packages first, as it will probably contain the information in which you're interested in a more condensed and accessible form.
for every maintainer script (.config, .postinst, et c) there are hunks of shell code which can be included by package maintainers. this way whatever the "best practices" are deemed to be, the latest version of this package and their scripts will implement it transparently for the packages which use them. for each maintainer script, there is a generic script and a database-specific script. that is, you will find scripts named:
#!/bin/sh # postinst maintainer script for foo-mysql # source debconf stuff . /usr/share/debconf/confmodule # source dbconfig-common stuff . /usr/share/dbconfig-common/dpkg/postinst.mysql dbc_go foo-mysql $@ # ... rest of code ...
Note the arguments passed when sourcing the script.
the skeletons for the underlying databases are found under this directory, in per-package subdirectories, underneath which are files specific to each of the individual supported database types. these scripts do not need to include the code necessary for creating database users or the databases themselves (this is taken care of elsewhere), only the data used to create the necessary tables and/or otherwise populate the database is needed here.
upgrades are probably the most complicated part of this common infrastructure. often in the life of a database application the underlying database needs to be altered in some way. in this implementation, for every file that matches the form
if $vers is more recent than the most recently configured version of the package (as passed to $2 in the postinst), then they are applied, in sorted order.
config contains the default global settings to be used during configuration.
$package.conf contains the per-package settings for database applications. these settings are fed into debconf, so whether if debconf is set to non-interactive mode these will be the authoritative values, otherwise they will serve as pre-seeded defaults.
all of these files are in a shell-script include format, such that they can be easily read and written by the common configuration scripts. they're generated and maintained via ucf, so this setup should be fairly friendly to the admin who wants to manually edit the files.