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

[Alexander Neundorf]

On Wednesday 30 December 2009, 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].

Would it help to have an overview over which FindXXX.cmake modules have been 
executed, which successful and which failed ?
(basically like the the feature_log, but complete, but OTOH less well 
formatted)
But I guess you mean per-app, right ?
One issue with doing things per-app is that while it makes dependencies 
clearer and apps easier to build separately, it does generate some duplicated 
code, which KDE developers in general try to minimize. 

> That is why I was so vocal about adding a "wrong dep" to kdelibs, just
> to make build files "simpler". 

If you mean soprano/SDO/nepomuk/virtuoso/redland/raptor, my primary intention 
was to unbreak the build.
For several weeks our build was broken, some parts were optional (in cmake) 
but hard required in code. This was just broken and needed to get fixed.
Since it seemed not much people seemed to care about this, I think I suggested 
to make it hard requirements. 
Either everybody would be ok with it or if not, at least we would get a useful 
discussion going with an actual result.
I think this is what we indeed have now.

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

I didn't forget, and it's still on my TODO. 2009 was a quite eventful year for 
me in real life (only good things), and there were enough other issues to 
sort out in KDE land (polkit, nepomuk, and more).

At least since a few weeks we now have KDE4_xxx_LIBRARY variables for all KDE4 
libraries also when building kdelibs, not only when using kdelibs. 
This is a (small) first step towards a more modular kdelibs.

Alex