[Dbconfig-common-devel] Questions about upgrading

[sean finney]

> > i *think* you can safely say yes here if you're upgrading, without it
> > trying to install a new database on top of your own.  
> 
> Would dpkg-reconfigure do any good, or will the fact that it wouldn't
> change package versions imply none of the dbconfig upgrade code gets
> run?

since you've successfully upgraded the package, when you reconfigure
the package the "old version" passed to dbconfig by dpkg will be
the same as the new version, and the upgrade script will not be
run.  in fact, i think it may try to install a new database.

> If dbconfig has code to detect an existing database, it may be that
> one or more of those issues (multiple DB's and versions, multiple
> ports, multiple client versions) caused the search to fail.  It should
> be using the database contact info from bacula's configuration; I'm
> not sure if it does.      

there's an option to import settings from pre-existing configuration,
but the maintainer must do something to enable this feature and it
doesn't seem he has looking at the source.  in any case, this is sitll
controlled by the master "on/off" install question.

as for postgres 7.4 vs 8.x, there isn't anything setup to detect
which version to use, which could be a problem for some mixed
environments, but it wouldn't be too hard to work out some detection
code and set a couple extra environment variables to psql.

> That's really useful to know.  There is so much stuff going on in
> dbconfig that I wasn't sure it was that simple.

it isn't always, and in this case even i think there's a catch:
it is possible that there are some substitutions that take place
in the sql code, so you might want to look through for anything
that looks like a template variable like _DBC_FOO_ or something.

> One of the reasons this approach concerns me is that if someone wants
> to subequently upgrade a database, either because they have multiple
> instances or because they are in a situation like mine, there is no
> obvious way to do it.  I gather from above that running the scripts
> manually is about right if you get the user and choice of database
> right.  But I gather dbconfig can do more than execute sql scripts on
> upgrade, and, again, there's no obvious way to access this
> functionality outside of package install/upgrade.

yeah.  ideally, the maintainer should still provide information on
how to perform installs/upgrades manually, even if it's "just run
x command < sqlfile".  i would consider opening a wishlist bug
against the package for this.


	sean

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060710/d86ce949/attachment.pgp