Hi, On Mon, Mar 17, 2008 at 09:57:33PM -0000, Frode M. Døving wrote: > - User PIM data is best stored in $HOME, migration to new machine/re-install > etc.
Agreed. However using mysqld as a backend storage in that scenario is uncommon. How would handle a mysql-server upgrade done by the system ? When upgrading to a new version, mysql_upgrade script should be run in order to upgrade the databases - for example upgrading from 4.1 to 5.0 required the modification of column field to handle longer password. This was automatically done during an upgrade by the package. How will you make sure that your databases are correctly upgraded when mysqld is upgraded on the system ? > - Settings for the mysql-daemon can be optimized for akonadi. What kind of settings do you think needs to be tuned for akonadi ? Aren't the default settings of mysql-server in hardy good enough ? > - This setup does not require root-access. (Except on ubuntu hardy, where you > need to disable/modify apparmor). > Using the default system install doesn't require root either. I'd also add that I don't know of any application in the ubuntu repository that spawns a mysqld process to handle their data storage. The best practice is really to use the system databases. Your first point is addressed by using sqlite3 rather than mysql. sqlite3 has been designed for these type of use cases. status incomplete PS: Please don't reset the status of the bug to New. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com ** Changed in: mysql-dfsg-5.0 (Ubuntu) Status: New => Incomplete -- akonadi does not work with the apparmor rules introduced for /usr/sbin/mysqld on hardy. https://bugs.launchpad.net/bugs/197476 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
