hi guys,

On Fri, Feb 12, 2010 at 10:40:05AM +0100, Klaus Ethgen wrote:
> Am Do den 11. Feb 2010 um 22:48 schrieb John Goerzen:
> > On Thu, Feb 11, 2010 at 10:13:37PM +0100, Klaus Ethgen wrote:
> > > And there is the point. I never ever get to this point where I could
> > > choose the option to update.
> > That is because you answered incorrectly to the first question.
> 
> Well, the question was really clear; if you have a existing database
> don't say yes to this question. So, no, it was correct. Maybe incorrect
> in the meaning of the logic but the correct answer to the question.

The question is definitely confusing, and i believe it's even been
reported before.  I think asking the upgrade question instead of
the install question would make it less ambiguous.  For reference:

Template: 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.

Technically, it might still be a bit misleading as upgrades might not
actually need to be performed, but it at least doesn't mislead the user
to select the opposite of what they probably want to select.  do you agree
that this question is better or should we draft a new question entirely?
Here's a proposal:

Template: dbconfig-common/dbconfig-import
Type: boolean
Default: true
_Description: Configure database for ${pkg} with dbconfig-common?
 This package now has the option to have its database managed with
 dbconfig-common.
 .
 If you want to handle the configuration of your database manually,
 you should refuse this option.  Otherwise, you should choose this
 option.

It still feels kinda lacking.  Perhaps someone else could suggest an
improvement?

> However, later on I tried to say yes here (with having a backup of the
> database) and I also didn't get asked to update the existing database.

this may be because you already upgraded, and were instead reconfiguring
at the new version level?  dbconfig-common itself doesn't keep much state
and instead relies on what it's given via the maintainer scripts.

> > You should have said yes when asked if dbconfig-common should
> > configure it.
> 
> But the question is about _creating_ and not _configuring_ it. At least
> as I read it.

yes, misleading it is!

> However, also if I say not to manage the database with dbconfig-common,
> there should be the update scripts anywhere around so I can use it
> myself. Maybe put it to /usr/share/doc/bacula/... Not wanting dbconfig
> to manage the database doesn't mean that the database do not have to be
> converted.

take a look under /usr/share/dbconfig-common/{data,scripts}/<pkg>, which
should have all of the sql and/or scripts provided by the package.  you
might not be able to execute it directly depending on whether they're using
some of the advanced features (scripts or template substitutions), but
it should at least get you started in the right direction.  that said the
aim of dbconfig-common is to make this as transparent as possible.

> > I am reassigning this to dbconfig-common and asking its maintainer to
> > make the wording on that first question more clear for people that are
> > upgrading packages from pre-dbconfig-common versions to
> > dbconfig-common versions.  I think that is the only bug here.
> 
> Maybe. This might be another bug. But this won't bring the update
> scripts for people who don't like the database to be managed by
> dbconfig-common. And let me say, I more and more dislike this package
> (dbconfig-common) to manage my database(s).

suggestions, feedback(, and ideally patches) are always welcome.

        sean

Attachment: signature.asc
Description: Digital signature

Reply via email to