hi martin, On Wed, Aug 03, 2005 at 09:15:03AM +1200, Martin Langhoff (nzl) wrote: > >but what about cases where an app has been configured for a remote > >database, and there's a package installed, and then the admin wants to do > >one locally. you're still in the same position as you'd be w/recommends. > > And I don't think we can get gracefully through the _reverse_ scenario, > where there's a local db but we want to use a remote one. Or perhaps you > mean that dbconfig-common will ask _always_? I read the following quote > and wonder: yeah, the reverse is true too. the problem is the existance or lack of either package can't serve for a basis for automatically doing something. dbconfig-common asks on a per-package basis. > > the presence of a db shouldn't necessarily imply that an admin wants > > to install locally on that db. with dbconfig-common they will still > > have the option of how to install. > > Finally, we have to deal with scenarios where there are several > webservers to one database backend. If we are dealing with db schema > maintenance and related tasks in postinst, one of the webservers should > be 'upgrade master' of sorts, and debconf should know about this. Some > apps deal with this at the app level. there are two corner cases: - many sites/applications, one database, from many packages. - many sites/applications, many databases, from one package. dbconfig-common can handle the first situation quite well. before both installations and upgrades it will prompt the local admin whether or not to do anything. you could therefore have all but the upgrade master set to not install/upgrade databases. the second situation is a lot trickier, though i have a rough sketch for how i'd like to implement it (should be backwards compatible). but first i want to see where things go with the webapps-common work before i spend too much time on it to make sure it will get along with the larger effort. sean --
Attachment:
signature.asc
Description: Digital signature