Re: dbconfig-common: near future change in dependency stack
Excerpts from Paul Gevers's message of 2015-12-06 05:23:07 -0800:
> Hi all,
>
> 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?
>
> 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:
>
This is great! Thanks Paul. I've never been very happy with
dbconfig-common because it kind of assumes databases are on the same
server as apps, which is increasingly not the case with smaller server
instances running in VMs, on the cloud and in containers.
> 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?
>
I have mixed feelings about this. I understand that in the very basic
case, doing this means that the user gets to move forward without having
to think about the server package.
However, I also think that postinstall is not the right time to
be configuring your database, and I'd rather see guidance in the
documentation and the fine wizard that is dbconfig suggested as a CLI tool
for users to use once they have thought through their database options.
So adding it to the Recommends just adds mystery to this process and
doesn't actually help users find their way to best practices.
But I understand there are many who do not agree with this position,
so my thoughts on this may not resonate with you. :)
Reply to: