Hi, 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. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature