I've been able to work around this, and have some news based on
exchanges with the dbconfig people. You can see the thread at
http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/2006-July/000547.html
for more details.
First, it is possible that if I had answered yes to the initial
question ("Configure database for bacula-director-pgsql with
dbconfig-common?") that dbconfig would have done the right things and
upgraded. It's also possible it wouldn't have (meaning it might have
done something very wrong, like wiping out my database).
The dbconfig developer said he would review the wording of that
initial question to see if it should be phrased differently--i.e., in
a way that invites a yes if you already have a database in an old
configuration.
Second, the debconf question says
"Details on what needs to be done should most likely be provided in
/usr/share/doc/bacula-director-pgsql."
This language comes from dbconfig templates; bacula-director-pgsql has
no such documentation, as far as I can tell. It's use is encouraged
by me and the dbconfig people :)
Third, I was able to convert the database by executing
psql bacula <
/usr/share/dbconfig-common/data/bacula-director-pgsql/upgrade/pgsql/1.38.0
as user postgres. I discovered this left various objects inaccessible
to the bacula user (new tables and sequences) and I had to assign the
right permissions so that things would work.
Presumably, if I had done this as the bacula user to begin with--which
I think is possible--I could have just run the script and be done. At
any rate, after running the script and fixing permissions I was able
to use bacula again.
Fourth, postgres supports multiple instances and multiple versions of
the database (e.g., 7.4 and 8.1). bacula is using the 7.4 database,
running on the default postgres port. This seemed to work OK, but
dbconfig isn't really designed for multiple instances or versions at
the moment, and it's possible some setups would fail to upgrade
because of this. In particular, if the bacula db is not running at
the default port, it seems possible it wouldn't be found. Perhaps the
postgres wrappers are smart enough to sort this out. Otherwise,
probably info from the bacula config about which database to use
probably needs to get to the upgrade routines.
P.S. dpkg-reconfigure would not produce an upgrade of the database,
since it would detect that the bacula package was already at the
current version and not invoke any update logic--or at least, so say
the dbconfig developers.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
