Partly an upstream query, partly a Debian packaging / lintian query: I've taken on development of a database-driven GNOME ORM IDE upstream[0], written in C, which will have a system-wide database to provide support for writing new applications using the IDE, those apps then work with a compiled interpreter (a separate package in Debian) and user-specified databases (and other datasources) via a variety of backends using files that are in userspace. i.e. the system-wide database is only needed for developers using the new IDE provided by the package, deployments of applications written using the IDE need their own config (but could use the main app as an example) and simply depend on the interpreter package. Connections to the various data sources can be via mergeant, libgda3 and other similar layers. The IDE produces an XML file containing the ORM mapping from the database to Gtk using Glade - passing that XML to the interpreter loads the Glade interface, populates the GtkWidgets with live data from the data source and runs the signals required to get the interface to do something with the data. (It could work with Qt if someone writes the mapping to something equivalent to Glade for KDE.)
(ORM as in Object Relational Mapping)
The system-wide database will also support the examples package and
thereby the yelp manual and user documentation by providing test data
that is common to all installations of the IDE.
The actual database client chosen for this system-wide database is up to
the user (although currently I've only been testing with PostgreSQL,
I'll need MySQL and SQLite to be supported before release).
It's early days and there won't be any real release until after Lenny
(partly because it will use libqof2 which itself won't be released until
after Lenny).
Therefore, I thought I'd use dbconfig-common to provide a debconf
frontend to allow the client to be chosen at installation time, setup a
database name and password (where needed) and support possibly remote
databases too (possibly not ideal but I can disable that later, maybe).
I can get the data out of dbconfig via the tools supported but I need
the IDE to get that data in a non-Debian-specific way when it is first
run. (The IDE itself is not Debian native, despite being hosted at
alioth.)
Rather than reinventing dbconfig by writing an entire wizard in Gtk,
(and as the data consists of only 7 strings), I thought I'd just parse
the dbconfig output in postinst and pass those values directly to
gconftool-2, *after* the debhelper parts of the postinst have actually
obtained the relevant values from the user. Other distros can then use
whatever tools they already have for similar tasks to dbconfig.
When the IDE loads, it can just look in gconf and all is well. (Other
IDE preferences can be added to gconf later via support in the IDE
itself.)
It works (so far) but lintian gives a warning:
W: estron-gnome: gconftool-used-in-maintainer-script postinst:45
N:
N: This script apparently runs gconftool or gconftool-2. It should
N: probably be calling gconf-schemas or update-gconf-defaults instead.
N:
W: estron-gnome: gconftool-used-in-maintainer-script postinst:48
W: estron-gnome: gconftool-used-in-maintainer-script postinst:51
W: estron-gnome: gconftool-used-in-maintainer-script postinst:54
W: estron-gnome: gconftool-used-in-maintainer-script postinst:57
W: estron-gnome: gconftool-used-in-maintainer-script postinst:60
W: estron-gnome: gconftool-used-in-maintainer-script postinst:63
Well, the postinst does call gconf-schemas via dh_gconf to put the gconf
schemas into place, but the 'defaults' aren't known before dbconfig is
run so I can't put the defaults into the package itself. Hence the
postinst calls dbconfig, then all the debhelper routines and finally,
inserts the dbconfig data into the gconf structure created a moment
before by debhelper, by calling gconftool-2 with the data from dbconfig.
(postrm and prerm handling is default debhelper and dbconfig so remove
and purge are handled cleanly.)
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
. /usr/share/dbconfig-common/dpkg/postinst.pgsql
dbc_pgsql_createdb_encoding="UTF8"
dbc_go estron-gnome $@
#DEBHELPER#
# pass the dbconfig data to gconf
DBUSER=`dbconfig-generate-include -f sh -u
/etc/dbconfig-common/estron-gnome.conf | grep dbuser | cut -d'=' -f2`
if [ ! -z "$DBUSER" ]; then
gconftool-2 --type string --set /apps/estron-gnome/dbuser $DBUSER
fi
...
The question is:
Is this a sane use of dbconfig and gconf?
Do I really need to write a Gtk wizard instead?
I'd still like to use dbconfig, so I would still end up using both
dbconfig (in Debian) and gconf (upstream) *as well as the wizard* which
would have to know how to get Debian-specific config data instead of
asking the user again so it would need to support some kind of
command-line configuration option to say "got config already in file
blah". Seems like a lot of work to me.
I get the impression dbconfig is geared more towards Web2.0 type stuff
rather than compiled programs.
[0] http://estron.alioth.debian.org/
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
