On Wed, Apr 18, 2007 at 02:20:15PM -0700, Cameron Dale wrote: > 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 | ...". > You know all that is good and will work best. Could it be made easy to satisfy the dependency, like "php5-mysql | php5-i-will-do-sql | ..."?
Perhaps with a better name though. I think I can then hack something together that will provide "php5-i-will-do-sql", unless in this day and age there is a better way. > >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 Thus far I'm un-aware of being or not being serious, however many have expressed this to me, no kidding. :) That said I do have perhaps a bit too much fun with any thing to do with designing a better Debian. Since I'm more or less inactive when it comes to actually working on Debian, these are mearly suggestions to be taken with a grain of salt and an open mind. > other databases. Torrentflux already uses a common SQL syntax, which > when combined with libphp-adodb makes it possible to use different An good point. Would it be possible to pkg the install and upgrade sql statements as a common libphp-adodb program/script? I can see the sql folder getting way over-bloated. One work around could be using a preprocessor(like for c, using #directives) to create the many types of SQL from a single definition file. As I indicated, this should be worked out with dbconfig-common. However the needs of this pkg and all the other pkgs like torrentflux should drive/define the process of furthered design/development. That's why it's important to list what is needed and/or could be made useful. I think a common framework for defining databases and possibly users may be in place, but it's(is it?) missing the framework for defining tables/fields/rows/permitions/ect. Torrentflux's actual needs may be far less then what I can imagine and will likely be less then what will be needed over all, but it's where I'd like to start. > 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. > I'm happy to continue testing. > 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 I just may, however I'm still looking for this fabled sqlite2-torrentflux.sql file. I may go as far as to build my own, even though I've been avoiding learning sqlite. It may not be a waste as more and more simple applications are depending on SQL. > 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. > IMHO, it's much better to access db files directly then to add SQL. Given a real need for SQL, sqlite is usually a poor choice. Perhaps the future may bring an obversion from depending on SQL, the way X11 was avoided in the past/present. > Thanks, > Cameron -- /**************************************************************** * Mike Mestnik: Junior Admin 612-395-8932 * * [EMAIL PROTECTED] VISI Inc. * ****************************************************************/ Alt address: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
