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

[Volker Krause]

On Wednesday 30 December 2009 17:53:14 Jorge Manuel B. S. Vicetto wrote:
> 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.

And what security risks would that be? Anticipating the usual answer here, 
open TCP ports, note that neither Akonadi nor Nepomuk starts their 
corresponding database server with a configuration that allows any external 
access, other than via a local unix socket, effectively limiting access to 
the corresponding user.

Regarding the "system wide" performance impact, note that the database servers 
only run when the corresponding service (Akonadi/Nepomuk) is needed by an 
application.
Also, consider the difference between MySQL embedded and stand-alone here for 
a moment. Why do you assume MySQL embedded is more resource-efficient than 
the stand-alone server, they do the same job after all? The only technical 
difference is that in one case you have all the code in one process while in 
the other case it's split between two processes using a local unix socket for 
communication. You have the same amount of code and libs loaded in both 
cases, you have the same amount of data buffers in memory, etc., the only 
difference is the additional overhead of a second process and the local 
socket communication, and that's minimal compared to all the rest.
Embedded databases do not magically make things more resource-efficient, they 
just move the resource usage to a different process.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20091230/0eb388bc/attachment-0001.sig