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. :)
