[Tracker] strigi 0.7 rc1

[Evgeny Egorochkin]

On Thursday 23 July 2009 11:52:46 Philip Van Hoof wrote:
> On Thu, 2009-07-23 at 07:31 +0200, Jos van den Oever wrote:
> > I've just uploaded Strigi version 0.7 RC 1 to
> > http://www.vandenoever.info/software/strigi/strigi-0.7-RC1.tar.bz2
> > This version is the first Strigi version using the Nepomuk ontologies.
> > For the KDE people: hooray, this can be used in KDE 4.3.
> >
> > For the Tracker people: yay, you can start using libstreamanalyzer
>
> Question for Evgeny:
>
> Does this libstreamanalyzer already take into account the latest changes
> that we made to the Nepomuk Message Ontology, for MIME files?
>
> In particular the nmo:hasContent changes that we made.

Not yet. I'm planning an overhaul of email analyzer. I'd really like to see 
his discussed and finally decided on first. Maybe NMO proposal is a good 
candidate for ticket-a-day :)

This pre-release is intended to compile a list of issues to be fixed. If you 
find any other, please let me know.

We're sort of forced to rush 7.0 out of the door, because we really have to 
break stuff^H^H^H^H change ontology before kde 4.3 is out. After this, minor 
releases aren't going to be a problem. This doesn't mean I consider 7.0 to be 
very broken. But I guess it still has some rough edges.

> Explained here:
> http://git.gnome.org/cgit/tracker/tree/data/ontologies/34-nmo.ontology
> http://live.gnome.org/Tracker/Documentation/EmailSparql
>
> > If you encounter any problems, please let me know, so the fix can make
> > it in 0.7 final.
>
> I wonder what the ideal way is to build a package just for libstreams
> and libstreamanalyzer, out of this release candidate. I also wonder
> whether packagers are instructed to package these libraries separately.

Deb guys will break it up. Actually it's already separated AFAIK. not sure 
about other binary distros. Might give them a hint.

For Gentoo it's going to be a sort of a problem. Gentoo guys usually prefer 
one package per one released tar.gz with a set of use flags to compile library, 
daemon, support for various deps etc. So it means than in gentoo tracker 
ebuild would depend on strigi ebuild. Alternatively if you can build 
libstreamanalyzer separately they might introduce two conflicting ebuilds for 
strigi and libstreamanalyzer with tracker ebuild being able to use either of 
them.

Which approach is taken depends on tracker guys being willing to be bashed by 
anti-kde trolls :)

I'm putting it on my todo list to ensure that there's an option to build 
libstreamanalyzer separately

P.S. just checked and it seems that if I run regular build commands in 
streamanalyzer dir, everything builds properly and is installed.

P.P.S. One more unresolved issue: libstreamanalyzer currently drags ontologies 
along. We might want to fix this to use shared ontologies, or rather fix it to 
not care about ontologies at all. The question is: should libstreamanalyzer 
try and validate analyzer output(especially 3rd-party analyzer output) against 
the ontology or should it be done at backend level?

--Evgeny