Package: debian-policy Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
It has been a while since the first version of the "Best practices for packaging database applications" was drafted by Sean Finney as the creator of dbconfig-common. The discussion on the document has died down a long time ago, but as the new (since last year) maintainer of dbconfig-common, I think would be appropriate to include or attach the database policy in the Debain policy. I asked the audience during my dbconfig-common BoF at Debconf 16 if they agreed with me, and the consensus was yes (for whatever it is worth). The current text of the "Best practices for packaging database applications" is contained in the dbconfig-common package and can be found on www.debian.org/doc¹. I attach current source to this bug report as a base-line of the content for discussion. What would be the best way forward? Is this appropriate for the policy? ¹ https://www.debian.org/doc/manuals/dbapp-policy/ch-dbapps.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlgzVm0ACgkQnFyZ6wW9 dQpeAAf9GKlvmaNxD9d+Glhis1XGvaMWawaE1AyRZIh+gA/eZrYTjHoAVE/vCBZi KyaMjscZdOz2A5wBNd+FAo9nnm3+hcG6u7o3ArIJghrWe4CD8zez6gVO35STMRJE G3bjVXxVThAHPs3i8x5mmZHcQhXOJVLBviwGTG8o2OjoukGzhUfCFpmyv/49b3TN STjDZ7dqq0Visx5yKVgQ270jh5STL3aI6dv3m8PFfanGdhjEvFG1/m2gtLs50mUA 6GPUwB+3oZZZGfxbFEKlonMy6cv9C61Cdir/qeVojVN+n/+6coqdhzIPIAfvd3Sf 999cqCieQHbGHYMp2nCPqGTTmnjiNQ== =F82r -----END PGP SIGNATURE-----Title: Best practices for packaging database applications
This document is licensed under the
In this document a "database application" is any program that
relies on some form of data storage outside the scope of the
program's execution. This is primarily intended to encompass
applications which rely on a relational database server or their
own persistent storage mechanism, though effectively is a much
larger set of applications. In the future this scope may have to
be narrowed to avoid ambiguity and be more effective as a policy.
For the purposes of this document, there are two types of
databases: persistent and cached.
Persistent databases contain data that can not be
entirely reconstituted in the case that the database is removed.
Also included are databases that if removed would cause serious
denial of service (making a system unstable/unusable) or security
concerns. Applications using this category of databases are
the primary focus of this document. Examples:
Cached databases are a specific group of databases which upon their
removal could be sufficiently regenerated, and could be removed without
causing serious denial of service or security concerns. Examples include:
Both persistent and cached databases fall under already
defined guidelines in the FHS; persistent data must be placed
under
The following descriptions are divided into different parts,
based on the action being performed. For each process, the
acceptable behavior of database application packages is outlined.
It must always be assumed that the local admin knows
more than any automated system. He/She must be given
the ability to opt out of any "assistance" on the part
of the package maintainer. Packages providing any such
automated assistance may do so by default if and only if
the opt-out debconf prompt is equal to or greater than
priority high. With this in mind, directions for manually
installing (and upgrading if relevant) the database must
be included in the documentation for the package.
For packages providing automated assistance, database
installation/configuration should be considered as part of
the package installation process. A failure to install
a database should be considered a failure to install the
package and should result in an error value returned by
the relevant maintainer script. Packages may provide a
"try again" option to re-attempt configuration. Any such
"try again" features here or elsewhere mentioned in this
document must have a default negative response value,
otherwise infinite loops could occur for noninteractive
installs.
To properly handle package reinstallation and
reconfiguration, any automated assistance must allow for
a package to be reinstalled at the same version without
removing or overwriting existing application data.
Package reconfiguration may do so.
Occasionally a new upstream version of an application
will require modifications to be made to the application's
underlying database. If an automated system is to assist
in such an upgrade, it should be considered as a part
of the package upgrade process; failure to upgrade the
database should be considered a failure to upgrade the
package. This is the only way to safely guarantee the
chance to reattempt the upgrade with respect to the
underlying database.
Furthermore, any automated system that makes modifications
to a database during upgrade must provide the ability
to back-up the database before proceeding. Packages may
perform such backups automatically, or prompt the admin
via debconf. Failure to back up the database should also
be considered a failure in the upgrade process of the
whole package. As in the case of installation, automated
assistance may provide a "try-again" feature to re-attempt
the upgrade, but ultimately in the case of failure should
cause a non-zero exit value to be returned to dpkg.
Note: if the database in question supports
transactional operations, it is recommended to do so.
A package should consider databases in a spirit similar
to configuration files or log files; they are something
to which the administrator may have some need even when
the software that created it is no longer present.
Packages may provide support for removing underlying
databases, but it is highly recommended that the
administrator is prompted with a chance to preserve
the data before doing so.
While not essential, a set of common tools for packaging and
configuring these applications can make the life of the maintainer
as well as the administrator much easier.
