[Dbconfig-common-devel] dynamic list of supported database types

[Niko Tyni]

On Sat, Mar 08, 2008 at 04:51:28PM +0100, sean finney wrote:

> On Friday 07 March 2008 02:20:51 pm Niko Tyni wrote:
>
> > I'd like to make sure that the admin is presented with a list of only
> > those dbtypes with the matching backend package (being) installed, mainly
> > to avoid errors due to missing libdbd-*-perl packages.  I've got this
> > working by setting an internal debconf variable from the rt3.6-db-*
> > config scripts and then building $dbc_dbtypes from those in the
> > request-tracker3.6 config script.
> >
> > Barring surprises in .config script execution order (which is what the
> > debian-mentors post was about), this seems to work. If the .config script
> > of request-tracker3.6 somehow does get run before the rt3.6-db-* ones,
> > I can always defer the configuration to postinst time.
> 
> why not call the dbc stuff diretly from the rt3.6-db-* packages?

The actual database setup is done by a Perl script that abstracts
the DB interface through RT's internal modules (currently in the
request-tracker3.6 package.) The database contents depend on other
request-tracker3.6 configuration items (like the name of the RT
installation etc.)

This would imply a circular dependency: request-tracker3.6
needs rt3.6-db-* to work, and the rt3.6-db-* postinst would need
request-tracker3.6 to be configured first if it is to do the dbc_*
stuff. And circular dependencies aren't a good idea if the order in
which the maintainer scripts are run matters :)

I suppose I could work around this by making request-tracker3.6
just an empty package pulling in the others, and having something like
rt3.6-config and rt3.6-lib as well. Seems like this would complicate
things even more, particularly wrt. moving configuration files from
one package to another.

I was also going to allow rt3.6-db-* coinstallability, but now that
I think of it, there's probably no point.

Cheers,
-- 
Niko Tyni   ntyni at debian.org