[Dbconfig-common-devel] Re: Bug#398634: [phpgacl] alternative patch without hard dependencies on both db clients.

[Andreas Henriksson]

On tor, 2006-11-23 at 21:02 +0100, sean finney wrote:

> unfortunately, this won't work because some apps work only with mysql,
> others with mysql | pgsql, others sqlite only, thus it's possible that

To me that means they should have exactly those dependencies!
Right now applications like "phpgacl" have to depend on both
mysql-client AND postgresql-client because it's supports both, but only
needs one (depending on which you choose).

(And yes, phpgacl could do this detection itself... but that would mean
we will duplicate it in about every package that uses dbconfig-common.)

> unless it specified its own dependencies, the app would be installed
> without any supported db clients installed. (phpmysqladmin on
> a system with dbconfig+sqlite already installed, for example)

My idea is that an application like "phpgacl" depends on
"dbconfig-common, postgresql-client | mysql-client".
Sends in $dbc_dbtypes="pgsql, mysql" to hint supported db types to
dbconfig-common and then have dbconfig-common only present the options
that actually works!
If phpgacl is installed on a clean system during this scenario a popup
sign shows "mysql is supported but the client is missing so that option
won't be available at this moment..." and then continues on with pgsql
as the only option.
If the user on the other hand personally prefers using mysql he has to
manually request that at the time of installing phpgacl ("apt-get
install mysql-client phpgacl"), which would mean that postgresql-client
won't have to be installed.
(Or if both clients are pre-installed he'll actually get to choose
between them during configuration.)

If the application on the other hand supports any database type it will
not depend on anything but just "dbconfig-common" and not pass in any
$dbc_dbtypes. That will then pull in one of the supported database
clients because of dbconfig-commons dependency on one, which will be
used... (this you are actually already checking, so I didn't have to
make any modifications... I also reused your helper functions in the
changes for the first case).

See attached patch for "proof of concept"....
(It's probably broken, but so are my english. I hope the patch explains
it better then I do with words...)




TODO:
It would probably be even better to not remove choices but instead
detect if a not-installed option is choosen and then show a note on how
to install the missing client and offer to safely abort or go back and
chose another database (since there is atleast one available that will
work)... This way there's no annoying popups telling you what you can't
do when you don't care, while giving you helpful hints when you do care.


Regards,
Andreas Henriksson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbconfig-common-skipunavail.diff
Type: text/x-patch
Size: 3752 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20061124/2bc5a0a5/dbconfig-common-skipunavail.bin