On Sat, Apr 21, 2007 at 09:31:07AM -0500, John Goerzen wrote: > On Fri, Apr 20, 2007 at 10:51:12PM -0700, Ross Boylan wrote: > > There are at least two problems that might thwart an automatic > > upgrade: > > 1) configuration files contain invalid parameters. > > That is true, but we can't do anything about that automatically.
So the question is how the package installation should behave in that case, and what the README should say about it. > > > 2) databases in non-standard places or servers. > > Well, this shouldn't be a problem. Was it you that reported having > trouble due to a misleading dbconfig-common question? If I had migrated the database to my 8.1 server, running on a non-standard port, the automatic upgrade procedure would not have found it. I did report earlier dbconfig-related issues in #371883. There's certainly overlap with some of the questions here. In particular, that earlier bug probably explains why I have dbc_install='false'. Maybe I should change it to true? I'm still not clear if dbc_install='false' implies dbconfig will not manage upgrades, given that dbc_upgrade='true'. But I guess my earlier problem, and the one here (in which the upgrade scripts don't seem to have fired) suggests that dbc_upgrade doesn't matter if dbc_install is false. At any rate, this all re-raises the issue of 371883: if the automatic procedure isn't run, by accident or design, what should the user/administrator do to set things up or upgrade manually? Although this seems like something dbconfig should manage, my recollection of prior discussion on the dbconfig list is that this is difficult to do reliably. For example, the scripts in dbconfig won't connect to a database in a custom location; they need to be run as a certain user; and they may make other assumptions (in the shell script parts rather than the sql) that aren't appropriate. As a user, the practical problem is that if things don't work right automatically one ends up with a system in a possibly unknown state. The upstream migration scripts are not available with the package (and probably wouldn't be quite right for Debian anyway), and the information in dbconfig is not accessible outside the installation process. (It is accessible in the sense you can read them, but working out what they do is not straightforward and there is no simple command you can invoke to fire them off.) Speaking of old bugs, I just noticed that I ran into the "No such file or directory" error before: #41345. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
