A lot of ebuild using a sql databases fiddle around with dependencies to catch the number of databases available with a "need". So please add a "provide <database>" and a virtual "provide sql" to all SQL database ebuilds. That way an ebuild can either specify a "need" on a special database system or a virtual need for a SQL database. Reproducible: Always Steps to Reproduce: Try to start/stop net-dev/dbmail without starting/stopping MySQL database Actual Results: Problems in start order Expected Results: Clean start order/dependency
how can the system know if your sql client app will use a local sql server (that needs to be started on the same system) or a remote one? you'll need to merge mysql to have its client libraries installed but you don't want it to start on systems with client-only stuff that use an rdbms on the network.
(In reply to comment #1) Is there any way in Gentoo for user defined dependencies instead of the static ones in the init scripts? Otherwise it would make sense to add a "need" with a comment to comment that line for remote databases or extend the baselayout to look for dependency information in /etc/conf.d/<config>.
(In reply to comment #2) > Is there any way in Gentoo for user defined dependencies instead of the static > ones in the init scripts? I'm not a gentoo init script expert, but AFAIK the only "user defined" way is to directly edit the init.d/* files :) The way I see it, adding mysql service to the default (or other) runlevel is sysadmin's responsability if he/she needs the db server running on that system. If you think about it, running "rc-update add mysql default" is the way you tell the system that you "need" it running. Regarding service ordering, there are "use" dependencies that do exactly that: specify that your service should be started after the ones it "use"s, but without actually "need"ing them if they are not part of the current runlevel. Anyway, IMHO the start order between an sql server and its clients shouldn't matter as far as the latter are well designed. A good app should retry to connect to the db and not quit at the first failure.
(In reply to comment #3) The main problem I've experienced is with Postfix. When you use LMTP for delivery of mails to the MDA and the MDA is not present, the mails go to nirvana. So if DBMail just quits because of missing SQL service, you loose mail. But also for using "use" in the init scripts you need the flags provided by the SQL services ...
we have virtual/mysql and virtual/postgresql*, they're probably enough to take care of database client libraries being present? for the init script side of things, I still thing it's not needed since this is after all a network service and it could be located on any system other than localhost. wrt the postfix/dbmail/whatever issue, that doesn't sound like a portage problem - you could look in using a monitoring solution and stuff like that.
(In reply to comment #5) > we have virtual/mysql and virtual/postgresql*, they're probably enough to take > care of database client libraries being present? The installation is no problem ;) > for the init script side of things, I still thing it's not needed since this is > after all a network service and it could be located on any system other than > localhost. If I understood correctly the "use" dependencies don't cause any harm on disabled services, but would avoid applications running into a timeout? > wrt the postfix/dbmail/whatever issue, that doesn't sound like a portage > problem - you could look in using a monitoring solution and stuff like that. I don't like the LMTP solution as you can loose hundreds of mails in just a minute until the monitoring system starts beeping and you reach the server. But the only alternative with dbmail is running the mails through pipes - and a poor mailserver sweating ;) So I'd generally prefer a clean start order (foundation to foundation and roof to roof, but not vice versa). ;)
(In reply to comment #6) > If I understood correctly the "use" dependencies don't cause any harm on > disabled services, but would avoid applications running into a timeout? Yes, sorry, I was thinking about 'need' when we were talking about 'use'. That would be probably the right choice.
Adding 'provide sql' is not a very good idea. It implies that the interface to all SQL databases are the same and compatible in the same sense as a log daemon or MTA. A virtual provide as that could also introduce complications with services still starting out of order, such as parallel booting or if both MySQL and PostgreSQL are present and running on the same machine, but one fails to start. And if it just so happens to be the one that fails is the one that is actually needed.... The PostgreSQL inits have long had 'provide postgresql' defined. (Which begs the question, why has this bug been assigned to us?) At least, if that slot had been set with the eselect module. That 'provide postgresql' will be unconditional, presently, along with the addition of 'provide postgresql-${SLOT}'. The idea being that most people will only have a single PostgreSQL server operating at a given time. If, however, there are multiple slots running simultaneously, the administrator only has to edit one init instead of multiples, or if a service requires a certain slot because it is incompatible with others. Which brings me to this: Much of what has been discussed in this bug is the responsibility of the individual administrator and not that of a Gentoo Developer.
As mysql-team: WONTFIX Postgresql team: Your call.
Negative.
