[PATCH] Making Soprano optional (again) in kdelibs

[Mike Arthur]

On 29 Dec 2009, at 23:43, Jorge Manuel B. S. Vicetto wrote:

> If "common sense" won't cut it, do I need to start a vote, forum thread
> or something else asking KDE users (I can do it for Gentoo alone) if
> they are worried/upset about this? Should I ask how many "former KDE
> users" stopped using it because of the MySQL dep?
> If you want, I can point you all to the user rants in Gentoo bugs about
> MySQL dependency for KDE as a whole and amarok as one particular KDE app.
> Why is it so hard to understand that KDE is getting more and more bloat?
> By the way, no other distributions / packagers have issues with the KDE
> dependencies?

Perhaps you could instead try to defend the decisions of the KDE developers and read the various FAQs stating why a relational database is being used and forward this to your users who are complaining.

http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F

This would be a good start to forward people to.

> As Maciej hinted, you're opening the door for another group of KDE devs
> later call for precedent to add hard deps on sqlite, postgres or
> whatever is their favourite DB. Requiring full blown relational
> databases for a DE is probably a good sign that someone is going in the
> wrong direction. Again, I can point you to comments by users in Gentoo
> bugs complaining about this - it's not just "my individual opinion".

Would you care to elaborate why you know better about the requirements of the PIM applications than the KDEPIM developers? As I stated earlier, feel free to write the code to match the performance and functionality without a database.

The idea that there will be another bunch of databases required doesn't really apply here as the two applications you've cited both use MySQL, making it more and more likely that any other KDE applications will start to use MySQL too.

Another way of looking at it which you perhaps haven't considered is that dependencies are a good things as they are shared, stable code that we don't have to maintain. This means KDE can get better rather than worrying about how to store information on disk. In KDEPIM, for instance, moving to Akonadi and using a database has allowed a lot of code to be removed.

Your concerns are known already, they were raised loudly when MySQL was first proposed for Akonadi and for Amarok. However, unless you have an actual technical solution to the problem that many of the KDE developers have tried to solve then raising these issues again is just demotivating.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk