Hi do you think such a configuration layer should depends on every database interface ?
Wouldn't it be cleaner to have the package using dbconfig depends on the database it can work with and have test in dbconfig to only show option regarding installed databases (or databases detectable via the already installed db client pacakges ? I don't feel well with the idea of a layer adding every client libraries even if no installed program can use most. A little rationale for this rant : Thanks for the test and though you put on dbconfig. I am not the developper but have already though of this problem too (but had no good idea to resolve it). The apache config layer currently in debain have the same kind of problem : it does not depends the scripts it uses (init scripts of apache, apache-perl ...). Thus if one have some installed , configure them with the apache config layer then one deinstall say apache-perl , it will be impossible to upgrade/desintall teh package configured with it. I removed apache-perl then the config layer tried to use /etc/init.d/apache-perl while upgrading phpwiki ... This layer needs those init scripts but does not depends on the packages providing them thus it can led to breakage. (i have not submitted a bug because i don't agree with the idea of adding hundreds hack to make it work, i am in fact "waiting" to see what will be done in dbconfig-common to manage this problem (as it is not yet heavily used and not in sarge , api/abi changes are way easier there.) If a solution to web application integration in debian is found it will be in this package or it won't be . This will also have interesting improvments for rich clients (but those have usually less complicated setups). Regards Alban PS: sorry if the style is a bit rude. I am always working on improving my english skills but debian comes first :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
