[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dbconfig-common: near future change in dependency stack


On 30-01-16 12:30, PICCA Frederic-Emmanuel wrote:
>> If a package relies on the dbconfig-common framework for database setup
>> and maintenance, installing dbconfig-no-thanks instead of one of
>> dbconfig's database-specific packages will block this function. It is
>> intended for cases where the system administrator desires or requires
>> full control of the database or where dbconfig-common makes bad choices,
>> and typically leaves the depending packages non-functional until
>> manually configured.
>> """
> If the no-thanks package is installed, what could be expected from
> the package maintainer in order to deal with the system administrator
> database mis configuration.

If the administrator installs dbconfig-no-thanks, he must accept that
the database for the package is not configured. By the way, this has
always been the case, but until now only via the debconf questions.
There are too many use cases where the admin wants to handle the
database creation and population differently, so a package should not
abort on that. Ironically, quite some package even (wrongly and in my
opinion unnecessarily) ignore the exit status of dbconfig-common just
for that reason.

If a package really, really, really must have the proper database during
installation, I would say you can only have that if you use a local file
type database like sqlite. MySQL/MariaDB/PostgreSQL are too often
running on a remote server where you have absolutely no guarantee that
you can perform the required actions. If you have such a (local file
type) case I guess it may makes sense to not alternatively depend on
dbconfig-no-thanks, such that you will always pull in the right
dbconfig-<dbtype> package. However, this will get in the way of the
administrator when she want to install another package that uses
dbconfig-common but doesn't want the dbconfig-common help.

> We just need to let the package un-configure in order to explain that
> the database is wrongly configure.

I don't think so, and I have the feeling (due to previous discussions
and several bug reports) that a lot of developers and system admins
disagree with you here. They want Debian to install the package, and
handle the database in a different way. If the package would remain
unconfigured, that disturbs other installs in an unpleasant way.

> Do we have something in dbconfig-common whcih could say, here ok I do
> not manage the database but with this sysadmin database
> configuration, the package is not working.

I don't think dbconfig-common can do that. If dbconfig-common goes out
of the way, either because dbconfig-no-thanks is installed or because of
a debconf answer, the admin should expect that the package doesn't work,
because he told "us" to not preform the required actions. I truly
believe that packages that require a working database connection should
not run havoc, neither during install, nor during automatic startup,
when the required database connection and content is not available.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: