akonadi does not work with the apparmor rules introduced for /usr/sbin/mysqld on hardy.

Is there any reason why akonadi starts its own mysqld process ?

This goes against common practice: most of the programs use mysqld provided by the system.

There are many.

- User PIM data is best stored in $HOME, migration to new machine/re-install etc.
- Settings for the mysql-daemon can be optimized for akonadi.
- This setup does not require root-access. (Except on ubuntu hardy, where you need to disable/modify apparmor).

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

1) mysql-updates
That's probably means kdepim must depend on a certain mysqld version and include conversion scripts when needed.

2) settings
The default settings are of course perfect for hardy for the default use case. We are talking about a specialised set up for storing pim data, which can and probably already is using special settings to optimize that.

3) rootaccess
Indeed the default install does not need a password for this. But that means you a) are storing private data system wide, which of course can be shielded, bus it wrong by design imho and b) the default no-password can be changed by the user and so requiring manual intervention by the user to setup Akonadi, which is currently not needed.

Last point:
It is not a matter of 'if' upstream will do it like this, it simply is done this way by upstream. 'We' need to deal with it. Another option is to add a conflict on apparmor, which would suck more.

After some discussion with the upstream developers and the Ubuntu security team, here is a proposal: akonadi should depend on mysql-server-5.0 and hardlink /usr/bin/mysqld.akonadi to /usr/bin/mysqld. akonadi should then be modified to start /usr/bin/mysqld.akonadi instead of /usr/bin/mysqld - so that the mysqld process won't be protected by a profile.

Sounds like a good idea. In the developer use-case one can just hardlink manually.

Marking won't fix in mysql. See https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/197476/comments/5 for a solution in the akonadi package.

Should be working since 0.82.0-0ubuntu2

May I suggest that the mysql package adds a hardlink itself, say /usr/sbin/mysqld-standalone or something, for use in other applications? That way each application that runs its own mysqld doesn't have to meddle with the hardlink maintenance, and it would presumably be a lot easier to do for the mysql-server package in its own postinst/prerm scripts.

A case in point (closer to my own use case) is that it'd also be more convenient for apps that aren't packaged as debs, but rather uses its own install script for classical /usr/local style installations.