FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-30-2008, 11:53 AM
Neil Williams
 
Default Mixing dbconfig and gconf

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/
 
Old 06-30-2008, 01:39 PM
Loc Minier
 
Default Mixing dbconfig and gconf

On Mon, Jun 30, 2008, Neil Williams wrote:
> Is this a sane use of dbconfig and gconf?

I might misunderstand what you're doing, but I think you're setting up
GConf default systme-wide. Usage of GConf for system wide
configuration (of default databases) is a bit weird, but it's valid, as
long as you only set system wide things such as system gconf defaults
or system gconf mandatory settings. Perhaps one way to do this is to
seed a /usr/share/gconf/defaults/foo file and run update-gconf-defaults
after that. I wouldn't recommend running gconftool-2 directly though,
unless you would do so in a very controlled location of the gconf path
which /etc instead really.

> Do I really need to write a Gtk wizard instead?

I don't think db configuration needs to happen system wide; I'd rather
expect each user to have per project database settings so it would seem
to me it's that a real UI to configure such stuff per-user and
per-project would be useful anyway.

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

Not quite sure why you target using dbconfig; I had the impression it
was mostly aimed at setting up packages, not for per-user data.

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-30-2008, 03:49 PM
Neil Williams
 
Default Mixing dbconfig and gconf

On Mon, 2008-06-30 at 15:39 +0200, Loc Minier wrote:
> On Mon, Jun 30, 2008, Neil Williams wrote:
> > Is this a sane use of dbconfig and gconf?
>
> I might misunderstand what you're doing, but I think you're setting up
> GConf default systme-wide.

Only for certain settings related to installed package selection. Much
like the system user for MySQL and PostgreSQL installations - in effect,
it is used to tell the IDE which backends are installed and the
configuration for each. Rather than ask the admin every time a new
backend is installed, each backend can use the one dbconfig config.

The IDE can then offer those amongst other userspace backend
configurations.

Think of it a bit like the reserved tables set up by MySQL and
PostgreSQL - the dbconfig data creates tables for estron-gnome that are
roughly equivalent to the internal tables used by the DBRM itself. The
applications written using the IDE then use their own tables, much as
any package would when using MySQL or PostgreSQL directly.

> Usage of GConf for system wide
> configuration (of default databases) is a bit weird, but it's valid, as
> long as you only set system wide things such as system gconf defaults
> or system gconf mandatory settings. Perhaps one way to do this is to
> seed a /usr/share/gconf/defaults/foo file and run update-gconf-defaults
> after that.

My problem is that the first time the IDE runs, it will need to have
this data available - hence the alternative of a Gtk wizard.

> I wouldn't recommend running gconftool-2 directly though,
> unless you would do so in a very controlled location of the gconf path
> which /etc instead really.

I don't follow - currently, the schema goes into:
/usr/share/gconf/schemas/estron-gnome.schemas

What do you mean about a gconf path from /etc ?

> > Do I really need to write a Gtk wizard instead?
>
> I don't think db configuration needs to happen system wide; I'd rather
> expect each user to have per project database settings so it would seem
> to me it's that a real UI to configure such stuff per-user and
> per-project would be useful anyway.

Multi-level - each "project" defines the datasource configuration and
can use any of the available methods. The gconf data only relates to how
the IDE offers optional backends. Each backend is a bit like a plugin
but each can have installation-specific config.

Once the application is developed within the IDE, it can be reconfigured
for another backend or another configuration, allowing site-specific
configuration.

e.g. an app written using PostgreSQL on one machine can be reconfigured
to work with a SQLite backend on a slower machine (and can support data
export -> import across backends too).

At each stage, the application config is separate from the system-wide
IDE config going into gconf.

> > 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.
>
> Not quite sure why you target using dbconfig; I had the impression it
> was mostly aimed at setting up packages, not for per-user data.

But that is how I'm using it - dbconfig is used to set up the IDE
package on a system-wide basis.

The IDE then allows the development of other applications that can
choose from a variety of data connections, including some that are
system-wide, some that are userspace and some that are remote. The
applications can have a *different* system-wide config to the IDE
because these can be packaged as individual packages themselves, just
depending on the interpreter.

estron-gnome: IDE
Offers a selection of estron backends, some of which need
configuration. Any backend can be installed as long as there is at least
one. It is this stage that needs the dbconfig/gconf config so that the
IDE can offer the backend to any project being developed - including the
ability to create a separate config for each project, hence the need for
a super-user, system-wide, config that has CREATE privileges.

estron: interpreter
Runs the IDE (which itself is written in estron) and all estron
applications. It is the only dependency needed by stand-alone estron
applications.

backends: sys-admin able to select whichever backend is most suitable
for that box. Available to the interpreter and thence to the IDE.

There is no user-specific config, as such. There is project-specific
config, this is then carried over into the standalone application,
embedded within the estron file itself. Someone else with the IDE can
then tweak the application and use a different data source. Some
applications will use personal passwords, some can be prepared as Debian
packages and have their own system-wide config.


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-30-2008, 07:13 PM
sean finney
 
Default Mixing dbconfig and gconf

hi neil,


On Monday 30 June 2008 05:49:25 pm Neil Williams wrote:
<snip>

i have serious trouble grokking what exactly you are doing, but should just
say that if you are interested in adding "missing features" etc to
dbconfig-common then the door is open at
dbconfig-common-devel@lists.alioth.debian.org


sean
 
Old 06-30-2008, 07:39 PM
Loc Minier
 
Default Mixing dbconfig and gconf

On Mon, Jun 30, 2008, Neil Williams wrote:
> Only for certain settings related to installed package selection. Much
> like the system user for MySQL and PostgreSQL installations - in effect,
> it is used to tell the IDE which backends are installed and the
> configuration for each. Rather than ask the admin every time a new
> backend is installed, each backend can use the one dbconfig config.

Ok, then one problem with it is that as soon as the user will have
gconf settings in place different from the default, any updates to the
default wont be visible anymore. It all depends how you layer your
settings and all, but it's quite likely that either you hide the
settings or don't make use of GConf at all.

Say you install mysql, launch the IDE, configure a DB, install
postgresql, remove mysql, launch the IDE, want to configure a new DB:
you don't see the new settings.

Not quite sure you want GConf for such data passing though.

> > I wouldn't recommend running gconftool-2 directly though,
> > unless you would do so in a very controlled location of the gconf path
> > which /etc instead really.
>
> I don't follow - currently, the schema goes into:
> /usr/share/gconf/schemas/estron-gnome.schemas
>
> What do you mean about a gconf path from /etc ?

Hmm so you change the schema itself, means it's not static data
anymore; I'd rather recommend using the gconf-defaults mechanism we
have in place which provides a nicer override mechanism -- if you're
changing only the defaults that is.

> There is no user-specific config

(That seems quite far from the GConf use case)

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-30-2008, 08:12 PM
Neil Williams
 
Default Mixing dbconfig and gconf

On Mon, 2008-06-30 at 21:39 +0200, Loc Minier wrote:
> On Mon, Jun 30, 2008, Neil Williams wrote:

> Ok, then one problem with it is that as soon as the user will have
> gconf settings in place different from the default, any updates to the
> default wont be visible anymore. It all depends how you layer your
> settings and all, but it's quite likely that either you hide the
> settings or don't make use of GConf at all.

OK, I think I'm going to go with it only during immediate
problem-solving whilst fixing other stuff and find a better solution
that does not involve gconf once I've got other stuff fixed.

> Say you install mysql, launch the IDE, configure a DB, install
> postgresql, remove mysql, launch the IDE, want to configure a new DB:
> you don't see the new settings.
>
> Not quite sure you want GConf for such data passing though.

I'm beginning to agree - GConf probably isn't the right choice.

I'll find another cross-distribution settings mechanism - maybe see
about allowing the dbconfig file to be included in an "upstream" file
using the named.conf.local type mechanism.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-30-2008, 10:08 PM
Josselin Mouette
 
Default Mixing dbconfig and gconf

Le lundi 30 juin 2008 * 12:53 +0100, Neil Williams a écrit :
> 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.

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

This is an interesting use. The GConf Debian packaging was not directly
meant for such things, but it is easy to use it this way. Just ship
a /usr/share/gconf/defaults/10_estron-gnome symbolic link to somewhere
in /etc. In the postinst, generate the file in /etc before #DEBHELPER#
and you should be fine (dh_gconf should add a call to
update-gconf-defaults).

You should not call gconftool directly, since it modifies the
system-wide defaults, in which you have no easy way to tell whether the
sysadmin has already modified the values. This is why gconftool should
remain the sysadmin’s tool and not used by packagers.

I don’t think it is wrong to use GConf for such things; just the
opposite, as GConf was precisely designed for layered configuration.

Cheers,
--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 

Thread Tools




All times are GMT. The time now is 12:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org