* Paul Gevers: " dbconfig-common: near future change in dependency stack" (Sun,
06 Dec 2015 14:23:07 +0100):
Hi Paul,
> TL;DR;1 if your package depends on dbconfig-common please update your
> dependencies when my version 2.0.0 hits the archive (I expect in two
> weeks).
> TL;DR;2 should the new dbconfig-<dbtype> packages recommend or suggest
> the database server packages?
Suggest.
> Since I took over the dbconfig-common package I have worked on the
> following feature in the dbconfig-common framework: binary packages to
> specify in the dependency chain which database types a package supports.
>
> The idea is the following. Each package that used the dbconfig-common
> framework to set up databases, should depend on dbconfig-<dbtype> |
> dbconfig-no-thanks instead of depending on dbconfig-common (as used to
> be the case and still works). What this solves is multiple issues:
>
> 0) Bug: 353617¹
>
> 1) Because there is an alternative, dbconfig-<dbtype> can depend on the
> command-line client for dbtype, instead of <your package> recommending
> it. Thus properly signifying the hard requirement of dbconfig-common to
> have the command-line client available.
>
> 2) For multiple dbtype supported packages the system administrator now
> has a way outside of debconf to select which dbtype he wants by
> installing the right dbconfig-<dbtype> package. Currently the question
> will still be asked though.
>
> 3) The system administrator now has a way to say no-thanks to
> dbconfig-common (by installing the dbconfig-no-thanks package) on the
> system level, rather than per package via debconf.
>
> As a bonus, I can now add the database server packages to recommends,
> which should make life of the less experienced user easier. Do you think
> I should do this, or should I leave the database server package at the
> suggests level?
>
> Anyways, so what do you need to do? If your package depends on
> dbconfig-common (dd-list attached), the only thing you need to do² is
> revisit your dependencies/recommends/suggest. If you properly followed
> the dbconfig-common documentation, you have a dependency on
> dbconfig-common and at least a recommends (but probably a depends) on
> the command-line client(s) for the database type(s) you support. You
> should replace these with a depends on dbconfig-<dbtype> |
> dbconfig-no-thanks. Two examples.
>
> a) your package supports PostgreSQL, your dependencies now are
> Depends: dbconfig-pgsql | dbconfig-no-thanks
>
> b) your package supports sqlite3 or sqlite, your dependencies now are
> Depends: dbconfig-sqlite3 | dbconfig-sqlite | dbconfig-no-thanks
Some questions for Tryton server:
The situation is
- Tryton server runs out of the box without configuration with a SQLite
database
- The (strongly) recommended database is PostgreSQL, but there is also support
for MySQL (and beta for Oracle)
- There is a standalone package called Neso (Tryton Neso), that provides a
simple combined setup of Tryton client and server (using SQLite), depending
on those two.
Would it be possible for the last point to skip completely the database
configuration (e.g. dbconfig* not jumping in at all, when tryton-neso pulls in
tryton-server)?
What would be the best way to handle the strong preference for PostgreSQL?
MySQL is supported for Tryton, but fails to complete some tests due to missing
Standard SQL compliance. So I dislike generally the idea to install a
client package for MySQL on a default system. The solution would probably be to
not implement at all the option for MySQL, right?
Since the production use of tryton-server usually needs some other tweaking to
be done in the configuration file, the use of dbconfig* for Tryton is limited
anyway. I prefer until now to provide a detailed configuration file and README,
but of course I am open to suggestions.
Thanks,
Mathias
> For those of you that backport their packages via the Debian backports
> achive, I will provide a backport of dbconfig-common once version 2.0.0
> reaches testing.
>
> Please speak up now if you think this is a ridiculous idea, if you have
> suggestions on improvements, if you have questions or otherwise.
>
> If people want to see how it all works for discussion, I am open to
> upload to experimental.
>
> And as always, please report bugs as you find them including wish bugs.
>
> Paul
>
> ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353617
> ² Be aware, if your package supports multiple databases, you still need
> to set the dbc_dbtypes variable in you config script.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Attachment:
pgp9EBijUN6su.pgp
Description: Digitale Signatur von OpenPGP