>>>>> "Christian" == Christian Grothoff <[EMAIL PROTECTED]> writes:
> Interesting, I didn't think there was much to the mysql-setup given > that there is mysql_set_permission. Well, as far as the current GNUnet documentation is concerned, setting up the database is quite a hurdle: http://www.gnunet.org/user_afs.php3?xlang=English#mysql mysql_setpermission is nowhere mentioned there. Also, for people like me, who never ever installed or worked or read about mysql (or databases in general), all this is non-trivial. Especially if your database breaks and you want to recreate it. Nobody would assume, that the delete command is named "DROP". And googling for that took me lots of time (googling for "mysql commands" turns up this: http://dev.mysql.com/doc/refman/5.0/en/mysql-commands.html which is completely useless, since database creatiion is in section "mysql data manipulation statemens" who would guess that?). > I wonder why you hardwired things like "~/.my.cnf" (where the path > maybe different and can be specified in gnunetd.conf) Oh really, I just overlooked. I also guess that the gnunet user and the username used for the database need not be the same? > and then ask the user to manually delete certain files -- given > gnunetd.conf and some grep/awk-ing (or using gnunet-update's "-g" > option) you should be able to determine all of those paths and > automate these bits as well. Well, I actually wanted to auto-delete those things, but I did not want to parse the config file from a shell script. Asking the user to manually delete was more like a todo entry so people like you can comment on how that could be done right :) > Especially for a Debian package, that level of automation might be > nice. Yes, that somehow was the point of my proof-of-concept script. > I'll be happy to add the script to contrib/; I just wonder if it would > just contribute to the wasteland of undocumented and largely unknown > scripts there. Absolutely positive. This was more meant for discussion on the mailing list. > Maybe we should make this one part of gnunet-update for the > 0.8.0-release? (for systems running gnunet-update when migrating from > 0.7.3?). > Comments? Further suggestions? Making this part of gnunet-update would not allow deletion of databases? If this were part of a Debian package, than complete removal of the package should also remove the database. Given your comments, I would propose the following: Add a new binary program to GNUnet: 'gnunet-mysql' (or similar name), that does what the shell script does, but uses GNUnet's config file parser to read and update the config file and create or delete databases, plus updating/invalidating all the meta-data files (bloomfilter etc.). I would like GNUnet to use a my.cnf file in the GNUNETD_HOME directory (if present). Such a private file could also be written by gnunet-update/gnunet-mysql without worrying about side-effects. I would even volunteer for implementation, but don't expect anything before may :) Well, or if somebody more qualified with mysql did the setup program, then I'd be happy to test and contribute Debian (un)installation scripts that (non)interactively configure the database. With my current experience sqlite performance is very weak compared to mysql (ie HDD LED constantly glowing). Any chance that mysql can be made the default for Debian/Ubuntu packages? cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
