[Kde-pim] [PATCH] Making Soprano optional (again) in kdelibs

[Kevin Krammer]

On Wednesday, 2009-12-30, Jorge Manuel B. S. Vicetto wrote:
> On 29-12-2009 23:09, Mike Arthur wrote:
> > On 29 Dec 2009, at 23:43, Jorge Manuel B. S. Vicetto wrote:

> >> 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".

An interesting observation around this topic is that while it is usually 
preferred to have shared implementations, some people seem to prefer that 
relational data organisation is reimplemented for every use case separately.

From a developer point of view this doesn't make sense since one would spend 
resource on work somebody with most likely better understanding of the problem 
domain has already done.

From operating system vendor's point of view it doesn't make any sense either 
since it will require to distribute a lot of different implementations which 
basically do similar things.

From a system administrator's point of view it is even worse since hand 
crafted code for special cases will be more likely to have bugs, even security 
related ones that implentations with a broad usage spectrum will not have or 
have fixed more quickly.

As I said it is quite interesting that this is common sense for almost all 
parts of the software stack but not for software handling relations between 
data.

> > 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.
> 
> I'm not addressing the KDEPIM module maintainers in particular here, nor
> am I suggesting I know more about it than the maintainers. I'm talking
> about the KDE dependencies on the whole.

Right. Probably better to discuss this in a new thread, this one seems to be 
focusing too much on implementations of dependencies instead of dependencies 
as a concept.

> > 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.
> 
> Given previous experience in many FLOSS projects, I very much doubt
> you'll be able to convince everyone to use MySQL. I suspect the more you
> insist on it, the more objection you'll get and more pressure for
> alternatives will show up.
> In case it isn't obvious, the real issue with using MySQL is that KDE
> shouldn't depend on one particular DB implementation as that may only
> serve to alienate users of others DBs.

I am not sure how much certain software depends on a certain implementations, 
i.e. I heard Amarok depends on variants of MySQL because they found supporting 
multiple DB syntax to be a nightmare.
Nepomuk is, as far as I know, using an abstraction layer but the only 
implementation having all necessary features so far is Virtuoso.
Akonadi also has an abstraction concept and the two known working 
implementations are MySQL and PostgreSQL.

It probably depends what kind of featues the respective program needs and how 
advanced the used SQL statements are.

Assuming you already have a virtual package of some sort for Soprano backends 
which Redland, Sesame2 and Virtuoso then provide, you could try a similar 
approach for Akonadi backend, i.e. let your MySQL and PostreSQL package 
provide that one, adding new ones as the become available.

And you probably also have a way to make one the default is the installing 
party does not select one specifically.

> > 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.
> 
> It seems you have misunderstood my comments. I have no objection for KDE
> to include dependencies on common, shared projects. My objection is
> about the hard dependencies, in particular to add such deps to kdelibs
> when they are only required for individual apps / modules.

Good point.
I think this has been a misunderstanding. People here assumed it would be more 
convenient to have core modules depend on things and not have to track 
individual apps usage of them, while packagers actually prefer tracking 
individual dependencies to keep dependency chains for other programs short.

> About my comment on full blown relational databases use, what I mean is
> that requiring a user to have a full mysql installation just for a DE is
> bad. I can understand using an embedded db (mysql, sqlite or other), but
> requiring a user to have a MySQL server running on a desktop doesn't
> make sense.

Actually this is not the case (in case this is referring to Akonadi).
While it can be configured to use a running MySQL server (or PostgreSQL 
server), the current default is to use a preconfigured private instance (so 
not to require user or sysadmin configuration steps) of MySQL (there as been 
work on allowing a similar setup using Postgres, but I am not sure if that is 
committed already or will be in Akonadi's next release).

> > 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.
> 
> I'm sorry if my comments are received as demotivating, that was not my
> goal. What lead me to post to these mls (after months of silence) is
> noticing that KDE wants to go further and add another relational
> database dep.
> Seeing how Maciej's email and patches were received, how some of you
> can't see why making such deps optional is important and as a KDE
> packager for Gentoo, I'm trying to get you to rethink about KDE deps and
> in this case to drop the soprano hard dep requirement.
> Two points I get the impression some of you may have forgotten is that
> not all users want the complete KDE DE and that some distributions do
> not force the complete KDE DE onto their users.

As I wrote above, I think the misunderstanding comes from assuming that 
downstream would prefer fixed dependencies while you actually prefer checking 
each application's runtime dependencies individually.
Or maybe it differs between downstreams, etc.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20091230/b737592d/attachment-0001.sig