On 4/18/07, Mike Mestnik <[EMAIL PROTECTED]> wrote:
I do love to finish installing a pkg only to find it's ready to be used. I understand the current dependency on php4/5-mysql is required for this to function, but then I see that you are missing dependences for this goal. dbconfig-common blows up even after trying to disable it's use and eventually mysql is called, falling as it's not installed.
I too love the non-work required of preconfigured packages, :) it's just not always possible to preconfigure for everyone's desires. The dependencies should all be there. The dependency on php4/5-mysql is required by libphp-adodb, the mysql-server is only a suggest as the server could be accessed remotely and be present on another machine, similarly the mysql-client is only a recommend as it is not required if you do not want to use the dbconfig-common automatic configuration of the server. The first dbconfig-common question should ask whether you want to use dbconfig-common to configure the db, and if you say no should just leave the db unconfigured. This *should* work, although I see it may not for you. I recommend filing a bug for that, either on the dbconfig-common package, if you think it's related to that, or on the torrentflux package, which I can then reassign to dbconfig-common if it turns out to be their problem.
> possible to run torrentflux using any database server supported by > adodb, so you should have no problem using the source from > www.torrentflux.com to get it working using the instructions you > linked to. Otherwise, you could try to just install the package with > minimum dependencies and no database, and then modify it using the > instructions you provided. (Note that you don't need to install a > mysql server or stand-alone client, only the php4/5-mysql package and > its dependencies.) > I think it would be safe to change this, since you will not make it past the install without a stand-alone client and presumably a mysql server.
As I said above, a stand-alone client is only needed for the automatic configuration of the database, and a mysql server could very easily be located on a remote machine. The dependencies are targeted at the minimum possible installation.
Please consider only suggesting the use of mysql. This problem is general enough that a general solution might work well.
This would require implementation of other databases in the package, and even then would not result in a suggest of mysql, but rather a dependency on "php5-mysql | php5-sqlite | php5-pgsql | ...".
What would this pkg/app requirer to be non-DB dependent? I'm thinking a common/root SQL syntax that can be compiled(fixed up) to run on many target DBs. A method to return the information needed to connect to these *arbitrary* DB systems, so the pkg could create a working config file that would work with both an app and libphp-adodb. A "common" pkg that would ask the debconfg questions to define the database and initialize it, dbconfig-common sounds like a good name.
I can't tell if you're serious/joking/sarcastic here, but this gave me a bit of a laugh. Anyway, the building blocks are all there to support other databases. Torrentflux already uses a common SQL syntax, which when combined with libphp-adodb makes it possible to use different database backends. And dbconfig-common supports several database backends (including sqlite). The work is in setting up the initial install and upgrade sql statements that will work for the other databases, and then testing the other databases. The testing will probably be more work. Currently I only use mysql, I'm not very familiar with the others, and torrentflux (upstream) also only officially supports mysql. However, I would like to add other database options to it eventually. If you'd like to help out by contributing patches and testing for sqlite, that would certainly encourage me to get this done, and I would probably focus on sqlite first then rather than postgre. Any interest there? Either way, thanks for bringing it to my attention. I have to admit sqlite wasn't even on my radar before, as the user base is somewhat smaller than postgre. Thanks, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
