This DD discusses considerations for disto packages of GNU Taler components, especially with regards to configuration and setup. We focus on Debian packages for now.
The current way that configuration files are handled does not work well with
automated setup tools and furthermore does not easily allow restoring
configuration files in
/etc/ that the admin deleted or manually modified.
The database configuration is currently handled inconsistently. While some packages use Debian’s dbconfig-common facilities, others don’t, even though they require a database for operation.
The guidelines in this document are based on pratical experience
with third parties setting up Taler based on the Debian packages
and scripting supplied by us (i.e.
This section contains the new guidelines that we want to apply to all our distro packages, specifically the Debian packages.
The “pristine” version of config files must be installed into
/usr/share/taler/etc-original. These files should not be modified by
tooling or the user. These files may contain direct placeholders or
placeholder comments that are replaced (but not in-place, only in
when the package is configured.
During the postinstall step, the files from
are copied to
/etc/ (using the
ucf tool on Debian) and, if required,
placeholders are filled in.
When using tooling to set up Taler, the tooling should not
use files from
/etc/ as template, but instead from
/usr/share/taler/etc-original or alternatively generate custom configuration files.
Rationale: Debian manages conffiles in
/etc/ with special logic.
In particular, when files are deleted from
/etc/taler and the package
is reinstalled (even with
--reinstall), there is no easy way for
tooling (or the admin) to restore the unmodified config files.
The only way to restore it is
apt install --reinstall libtalerexchange -o Dpkg::Options::="--force-confmiss", which might be unsafe as it forces
overriding of all config files of the package.
The same considerations apply to configuration files of HTTP servers (nginx, apache, caddy, …). Additionally:
sites-available/exchange.$domainare unacceptable, as they are very difficult to uninstall or remove when
Packages should not use
dbconfig-common. Reasons are:
dbconfig-commonis lacking in documentation and very difficult to use for packagers.
dbconfig-commonoffers too much flexibility and asks too many questions to the administrator, especially when reconfiguring a package. The
taler-merchantpackage currently breaks when the user chooses anything else than
debconfig-commonmakes the database setup logic difficult to test. That is not a problem with simple packages, but most Taler packages require a non-trivial database setup.
dbconfig-common; even fewer are notable or widely used packages.
Instead, each package should document how to set up
the database and optionally ship an executable named
taler-$component-dbinitif applicable and unless supressed by the user.
For now, our tooling shall only support PostgreSQL and only set up
authentication or set up
password authentication with a random password for
components that do not support DB connections via unix domain sockets.
deployment.git) have been adjusted to use the configuration file templates shipped in the package, instead of using their own config templates.
(This should be filled in with results from discussions on mailing lists / personal communication.)