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

Wed Dec 30 17:53:14 CET 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-12-2009 11:45, Kevin Krammer wrote:
> 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.

I agree fully with your argument. We (Gentoo) do prefer to have
dependencies on shared and reliable packages than to have packages with
"home-grown hacks" or local forks. In that spirit, we actively unbundle
bundled libraries already present in Gentoo (a common source of security
issues with packages).

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

As a packager, I would very much appreciate clear and complete deps for
each app than having to scroll through all the CMakeLists.txt files and
determine the correct deps for each app in a module[1].
That is why I was so vocal about adding a "wrong dep" to kdelibs, just
to make build files "simpler". Especially since it meant adding a lot of
"bloat" to all KDE installs.

 [1] - This is exactly what we talked about with Alex in FOSDEM'09 as I
mentioned in the first e-mail. In our view, it would be simpler to get
the dependencies correctly fixed, if the current modules were split and
or each app was fixed to be built on its own - without relying on the
build of the complete module.

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

I can't talk about other distributions, but you're right about Gentoo.
Thank you for making my arguments clear and for addressing them.

> Cheers,
> Kevin

PS - To answer your question about "full blown relational server", we
mean having a complete DBMS environment, thus including a server
process, instead of having a simple embedded DB.
In case you're wondering, it's not about having a statically linked DB
in each KDE program that requires use of a DB. In fact, we do prefer
shared libraries and that's why I cared enough to get libmysqld built as
a shared lib. It's about having a DB server instance running on a
desktop, with the impact on system performance (system wide and not
specific to any KDE app) and exposing unaware users to security risks.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAks7hXoACgkQcAWygvVEyAJ6EQCeJEEtkK0rn208hScMumtjKT6G
7IwAn3v9mAPO3I9qd89hjbZu1S3bM0tT
=Qslw
-----END PGP SIGNATURE-----