Mark Knecht posted on Wed, 22 Feb 2012 15:24:11 -0800 as excerpted: > On Wed, Feb 22, 2012 at 2:39 PM, Kevin Krammer <kevin.kram...@gmx.at> wrote:
>> The problem seems to be that the Akonadi server configuration says that it >> should be using a MySQL instance for its database needs. >> > > Might this have been be created by me having MySQL installed at one > time, KDE choosing to use it, but it not being installed now? I bought > a book on MySQL awhile back just to run through a bunch of learning > experiments but then later removed it. All Gentoo dependencies are > being met so maybe an ebuild needs to be improved or something. FWIW, as a gentooer, kdeer and former akonadi/kmail user here, I know enough of the history to explain what's going on. The problem is indeed historical, but it has nothing to do with your former mysql interest. Instead, here's the sequence. There are AFAIK three possible akonadi-server backend databases, along with their drivers, mysql, sqlite, and postgresql, and in gentoo, the corresponding USE flags for that package (akonadi-server, you can verify the USE flags and their state). Back in the early kde4/akonadi days, to the kde 4.5.1 and akonadi-server 1.4.0-r1 time frame if you correlate the gentoo changelogs for akonadi- server and say kdelibs, the mysql backend was the default, gentoo following the upstream kde/akonadi lead, as it was the first to mature and early-on the stablest. However, mysql, while arguably a great full-sized database for those willing to take the time to properly tune and administer it (that is, professional server administrators), isn't particularly well suited to "I just want it to work" installations (that is, average joe blow desktop users). Among other things, mysql has at least a history of version upgrade challenges that can involve converting the database as part of the upgrade, and various weird (from the perspective of non-professional non-server-admins who just want it to work) problems with calendars and utf-8 charset issues. Meanwhile, the sqlite backend was maturing and its capacities and stability improving. Sqlite's history of course is as an application library, and it originally had problems with multi-threading and concurrent thread-safe access to the same databases from multiple threads. But by late 2010 under the pressure of akonadi intended usage, it had grown these features while still remaining much less of a problem to properly administer and upgrade than the previous mysql default, so first kde/akonadi and then gentoo as well, switched to the sqlite backend by default. Here's one of two entries, same day, from the gentoo akonadi-server changelog, that cover the switch: 07 Sep 2010; Maciej Mrozowski <reave...@gentoo.org> +akonadi-server-1.4.0-r1.ebuild: Enable SQLite backend as default one, fix SQLite driver name (QSQLITE3 is new one, adjust qt-sql USE dep) Again, correlating with the kdelibs changelog for kde timing perspective, that was right after kdelibs 4.5.1 was added to the tree on 06 Sep 2010. Of course, that change would have hit stable rather later. From the changelog again, it appears that would have been May 09 2011 (x86 and amd64), with akonadi-server 1.5.2, parallel to kdelibs 4.6.2-r3 stabilization (again, x86 and amd64) on the same day. OK, the default changed, which meant that new users installing it would get the new setup. However, gentoo by policy does not muck with files in a users's home dir: that's strictly up to the user and/or local admin. The PROBLEM was that unlike MOST kde settings, where a system level setting is the default and a user level setting doesn't appear unless it is specifically changed from the default, in THIS case, the akonadi- server active backend setting is stored in the USER config. Thus, what happened is that local admins who had set no specific USE flag preference manually, had the system default backend switched out from mysql to sqlite, with the resulting change in dependencies and actually installed packages if they kept up with emerge --depclean, removing no longer needed package dependency cruft from their system. But that did nothing at all to change out the already set user configuration in $HOME dirs, on systems where akonadi had been installed before the switch. These configurations remained mysql, until users switched them manually. If the only thing that had pulled in mysql was akonadi-server and an admin did an emerge --depclean before the user had switched, they'd suddenly find themselves with a broken config! One of the reasons this didn't hit more folks is that not everybody actually uses akonadi or the various kdepim apps that use it, so it didn't really matter to them. Another is that amarok continued to depend on mysql, so anyone who had it, or for that matter, anything else depending on mysql, installed, wouldn't have lost mysql. Yet another is that a lot of folks don't regularly run emerge --depclean or otherwise clear the old dependency cruft that's no longer pulled in as a current dependency, and they'd have not seen the problem unless or until they did. And of course there's the folks that don't upgrade very often in any case, and never run emerge --update --deep when they do, in which case the old mysql-default version would have stuck around for some time, until it was removed from the tree and the user next did a tree sync. So it would have only affected those who were simply using the gentoo default-use for the package or who specifically changed it themselves, who didn't still have mysql in their dependency tree for other reasons, and even then, it would have taken quite some time to filter down to the last stable user, updating only a few times a year and never doing --deep upgrades. >> Since you want SQLite instead you'll have to modify that. >> I am not sure if Gentoo has patched the sources to make that >> the defaut in case the config is missing or whether you have >> to change the driver key manually. >> >> In case of the latter, open ~/.config/akonadi/akonadiserverrc >> and look for the section labelle [%General] >> >> In it should be an entry like this: >> Driver=QMYSQL >> >> Change that to >> >> Driver=QSQLITE3 >> > The file is there but I want to double check. The only line I change > is the Driver=QSQLITE line. I don't bother with the MYSQL section and > SQLITE doesn't require a section of its own? Having done that change here myself (very shortly after it was introduced in Sept. 2010 IIRC, or even earlier when it hit the overlay, as I'm ~arch and running the gentoo/kde overlay, here, regularly check the git whatchanged logs for the overlay, and was by that time already quite fed up with the various mysql issues... and of course looonngg before I dumped kmail and then kdepim and akonadi entirely after getting fed up with the kmail akonadification with kdepim 4.6 and 4.7)... Yes, that's ALL you need change. If you want, you /can/ remove the mysql stuff as it's obviously no longer doing anything, but the single Driver= line change is the operational one, the rest can be left in case you ever install and switch to the mysql backend again, or removed, as desired. And sqlite being the much MUCH simpler "just works" solution (unlike mysql, perfect for a desktop default), there's really nothing to configure for the sqlite/QSQLITE3 driver; only to change to it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
