[Dbconfig-common-devel] Re: Not sure this is a dbconfig-common problem

Tue, 03 May 2005 17:22:56 +0200

This is a multi-part message in MIME format.
--------------030207020906050109010901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sean Finney wrote:

>aha.  that actually brings up something i haven't thought of.
>dbconfig-common handles retrying upgrades when the prevoius db upgrade
>failed, but it doesn't so much work if the db upgrade succeeded and
>something failed later on in the postinst causing the upgrade to fail.
>  
>

One solution (or at least part of it) would be, to always store the last 
successful update-version in the debconf-db and to never apply updates 
<= this version.
This would at least avoid to apply an update, that already has been done.

>thing that comes to mind is making db upgrade failures a little
>"softer", so that if the upgrade failed, the admin could see what
>went wrong and decide it it was worth continuing or retrying.
>  
>

I think the admin should be given the chance to Retry, Abort and Skip.

>>So far, everything works well. I'm just not sure, how to handle changes 
>>in the applications ini-config and how to upgrade from existing 
>>    
>>
>i think ucf is the way to go here.
>

I try to avoid this. The ini-config changes frequently, because it 
contains settings, that the user can change from within the application.
Currently I think more of something like this:

debian/config:
ini2dbc()
do_dbconfig-common_stuff

debian/postinst:
do_dbconfig-common_stuff
dbc2ini()

Why not povide such two hooks for appConfig2dbc() und dbc2AppConfig(), 
which the maintainer can provide by default?

Something like:

dbc_load_config=/usr/share/myPackage/dbcLoadConfig.sh
dbc_save_config=/usr/share/myPackage/dbcSaveConfig.sh

After loading dbconfig-common's default config file, it calls 
dbc_load_config and after saving the default config, it calls
dbc_save_config.

Tobias

--------------030207020906050109010901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean Finney wrote:<br>
<br>
<blockquote cite="mid20050503140831.GA6746@seanius.net" type="cite">
  <pre wrap="">aha.  that actually brings up something i haven't thought of.
dbconfig-common handles retrying upgrades when the prevoius db upgrade
failed, but it doesn't so much work if the db upgrade succeeded and
something failed later on in the postinst causing the upgrade to fail.
  </pre>
</blockquote>
<br>
One solution (or at least part of it) would be, to always store the
last successful update-version in the debconf-db and to never apply
updates &lt;= this version.<br>
This would at least avoid to apply an update, that already has been
done.<br>
<br>
<blockquote cite="mid20050503140831.GA6746@seanius.net" type="cite">
  <pre wrap="">thing that comes to mind is making db upgrade failures a little
"softer", so that if the upgrade failed, the admin could see what
went wrong and decide it it was worth continuing or retrying.
  </pre>
</blockquote>
<br>
I think the admin should be given the chance to Retry, Abort and Skip.<br>
<br>
<blockquote cite="mid20050503140831.GA6746@seanius.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">So far, everything works well. I'm just not sure, how to handle changes 
in the applications ini-config and how to upgrade from existing 
    </pre>
  </blockquote>
  <pre wrap=""><!---->i think ucf is the way to go here.</pre>
</blockquote>
<br>
I try to avoid this. The ini-config changes frequently, because it
contains settings, that the user can change from within the
application. <br>
Currently I think more of something like this:<br>
<br>
debian/config:<br>
ini2dbc()<br>
do_dbconfig-common_stuff<br>
<br>
debian/postinst:<br>
do_dbconfig-common_stuff<br>
dbc2ini()<br>
<br>
<br>
Why not povide such two hooks for appConfig2dbc() und dbc2AppConfig(),
which the maintainer can provide by default?<br>
<br>
Something like:<br>
<br>
dbc_load_config=/usr/share/myPackage/dbcLoadConfig.sh<br>
dbc_save_config=/usr/share/myPackage/dbcSaveConfig.sh<br>
<br>
After loading dbconfig-common's default config file, it calls
dbc_load_config and after saving the default config, it calls <br>
dbc_save_config.<br>
<br>
Tobias<br>
<br>
</body>
</html>

--------------030207020906050109010901--