Klaus Ethgen wrote:
> Well, I was updating from version 3.xxx to the new version. As the 2.4
> version is pretty old I think there are many people out there using the
> 3.x version in production.
>
> Additional, the debconf message just gives the options to create the
> database or to _not_ create it. There is no option to choose if you want
> to upgrade or not.
That is not what my code and testing reveal.
First I will be asked the dbconfig-install template, which says:
Description: Configure database for ${pkg} with dbconfig-common?
The ${pkg} package must have a database installed and configured before
it can be used. This can be optionally handled with
dbconfig-common.
.
If you are an advanced database administrator and know that you want
to perform this configuration manually, or if your database has already
been installed and configured, you should refuse this option. Details
on what
needs to be done should most likely be provided in /usr/share/doc/${pkg}.
.
Otherwise, you should probably choose this option.
If you answer yes to that, then you will see
dbconfig-common/dbconfig-upgrade
Type: boolean
Default: true
Description: Perform upgrade on database for ${pkg} with dbconfig-common?
According to the maintainer for this package, database upgrade
operations need to be performed on ${pkg}. Typically, this is due to
changes in how a new upstream version of the package needs to store
its data.
.
If you want to handle this process manually, you should
refuse this option. Otherwise, you should choose this option.
During the upgrade, a backup of the database will be made in
/var/cache/dbconfig-common/backups, from which the database can
be restored in the case of problems.
I can see how the wording of the first question may be confusing in the
case of an upgrade from the pre-dbconfig-common situation. I can
document that in README.Debian or reassign this bug to dbconfig-common,
because that wording does not come from the Bacula package.
> When you choose not to create the database (cause you know it is
> existing and you don't want to destroy it) then the daemon will not
Saying that you want dbconfig-common to manage the database doesn't mean
that dbconfig-common will destroy it, for sure!
>
> I was not asked about. I only had the choose to create the database or
> not.
More precisely, you were asked whether you wanted dbconfig-common to
"configure" it, though I can see the cause of confusion there.
> By the way, the dbconfig-common package seems to be in a very bad state
> as ucf throws a big warning about using it the wrong way. However, that
> is only about the later created config file and it still works, that is
> only a warning.
dbconfig-common fixed that in 1.8.43, uploaded a couple of weeks ago.
> As I told above, I think there are many people out there still using the
> version 3.x. Another reason is that upstream dropped support for the 2.x
> version long ago and forced users to use the 3.x version. Additional if
> I read correct the upstream only official support update from 3.x to
> 5.0. No earlier versions are supported.
That's not correct; there are update scripts going back years and years
still shipped with the 5.0 tarball. Like I said, I see no reason why an
upgrade from 3.x should fail, as I have put in to the code the features
needed to make it work. But it will never wind up in a Debian stable
release.
-- John
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
