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

[Sean Finney]

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hi tobias,

On Tue, May 03, 2005 at 05:22:56PM +0200, Tobias Grimm wrote:
> One solution (or at least part of it) would be, to always store the last=
=20
> successful update-version in the debconf-db and to never apply updates=20
> <=3D this version.
> This would at least avoid to apply an update, that already has been done.

i don't like this solution, for a couple reasons:

- Debconf Is Not A Registry(tm)

  what happens if the admin blows away the debconf database?

- It requires keeping state

  currently, nothing else in dbconfig-common requires keeping any
  kind of status or state outside of what dpkg already knows.  the
  benefit of this is there's less of a chance for something to go
  wrong.

> >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.
>=20
> I think the admin should be given the chance to Retry, Abort and Skip.

hah.  "Abort, Retry, Fail:".  reminds me of the good ol' days in dos.

this is actually a general feature that i think would be nice to have
in dbconfig-common, not just for upgrades but also for installs and
removals.

> >>So far, everything works well. I'm just not sure, how to handle changes=
=20
> I try to avoid this. The ini-config changes frequently, because it=20
> contains settings, that the user can change from within the application.
> Currently I think more of something like this:

i don't really see how this is a problem.  if the ini file is generated
=66rom d-g-i (either directly or indirectly), put into ucf, and the local
admin modifies it (even the db-related settings), the file won't be
overwritten.  in fact, the admin will not even be prompted with anything
unless you change the underlying template or reconfigure the package (in
which case they would probably like very much to be prompted).  of
course it would be nice if the settings could trickle from this file
into the dbc config file.


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

> dbc_load_config=3D/usr/share/myPackage/dbcLoadConfig.sh
> dbc_save_config=3D/usr/share/myPackage/dbcSaveConfig.sh

that's an interesting idea.  i'l have to think about the
logistics of how that'd work, but i think it would be
feasible


	sean

--=20

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCd7q3ynjLPm522B0RAtPrAJwKKoFvKo0NBSikJ1Uxs/sD1JpzwQCfdFMx
FL3dd4ZzhxvtRLOtHtDmLro=
=d0hr
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--