On Mon, Jun 10, 2002 at 03:47:10PM +1000, Matthew Palmer wrote: > On Mon, 10 Jun 2002, Giuseppe Sacco wrote: > > Actually when installing an application that for instance uses a DBI or > > PHPlib interface you have to scan for every database engine installed and > > then ask the user to select one of them. After choosing the engine you > > have to select a database instance name and some users/passwords. > > When you upgrade a database engine you would probably need to stop > > applications that uses the engine and then restart them. > > When you want to uninstall applications you could remove the associated > > database instance. When you remove database engine you could ask the > > user to migrate to a different engine. > > I would like to have some infrastructure to support all these operations > > in a standard way. > It's not absoloutely standardised, nor perfect most likely, but I seem to > recall an example in some Debconf documentation to do an almost identical > thing. There is also a system to do precisely that in the X servers to > select which X server to use as the default. It lists the X servers > currently installed and asks which one you want to use. I'd suggest going > to the debconf docs and, more importantly, the X server config scripts. > Write a generalised interface to this sort of hooplah (assuming the debconf > interface is too clunky - I don't think it is) and get everyone - databases, > Java programs (ugh), and X server - to use it, and the world will be a > better place. My principal objection to this talk of automatically scanning for available database engines is that it ignores the fact that SQL servers are *servers*, that is, there's a client-server architecture here which doesn't require the database engine to be installed on the local host. In fact, at work we have centralized database servers that we connect to from a number of other machines, so any configuration tool that lets me choose from a list of locally-installed database engines is worse than useless to me. Rescanning when the database *driver* package is removed might be acceptable, though. Otherwise, generalized, reusable debconf code for handling complex administration tasks would be a good thing, IMHO (so long as it's written right :). Steve Langasek postmodern programmer
Attachment:
pgpWAzU89tXlW.pgp
Description: PGP signature