The shared-desktop-ontologies mess

Andreas Pakulat apaku-Mmb7MZpHnFY at public.gmane.org
Thu Nov 26 14:13:45 GMT 2009


On 26.11.09 14:53:03, Sebastian Trueg wrote:
> I want to apologize for the mess I made in kdelibs yesterday evening. I
> can understand that you are frustrated especially with the beta1 tagging.
> 
> Let me explain the whole idea of the shared-desktop-ontologies package:
> In Nepomuk as in projects like Tracker and Strigi we need the ontologies
> to describe our data and to create user interfaces. This only makes
> sense if we use the same ontologies so that the data we create is
> compatible. We have been struggling to create this package for a long
> time. Putting it off even longer increases the possibility of ontology
> forking and incompatible data even more. On a more practical note
> without this package we need copies of the ontologies in several modules
> like kdebase or kdepim for example.
> 
> Now if the big part of you think this was too bold a move and should be
> reverted - I can understand that. In that case we have two possibilites:
> 1. put the ontologies in kdelibs (maybe even as a fallback in case the
> shared-desktop-ontologies are not installed)

That would mean creating some CMake API that needs to be working and
maintained until the end of KDE4 (I'm assuming the ontologies are needed
during the build of those modules). So this would best be what is needed
anyway, and kdelibs just installs those files the same as the
ontologies-project would do.
 
> However, if you think it was bold and not very community but what's done
> is done then I will try my best to get the cmake issues fixed (once I am
> told what they are ;)

Well, given that apparently at least kdepim already adjusted to the new
ontologies-stuff and already uses the (half-baked) new cmake module I think
its best to move forward instead of backward. Distributions should be
notified asap to package the new dependency and more importantly we need to
let the release team( cc'ed on this mail) know that right now there are
unresolved build-issues with trunk and that tagging and release need to be
delayed (as far as I understood they want to do that anyway as the kde
4.3.4 release is scheduled for the same time).

I'll try to have a look at the cmake module tonight to see what exactly is
problematic in there and will post the results.
 
-- 
A long-forgotten loved one will appear soon.

Buy the negatives at any price.



More information about the kde-core-devel mailing list