On Tue, Oct 9, 2012 at 1:24 AM, John Layt
<jlayt@kde.org> wrote:
On 8 October 2012 14:51, Vishesh Handa <
me@vhanda.in> wrote:
> For 4.10, Nepomuk will no longer depend on Strigi for file indexing. We have
> written our own file indexer which are based on popular libraries such as
> taglib, exiv, ffmpeg, etc. This allows us to better control the indexing
> process. If you would like to know more reasons as to why the change was
> done, please read [1].
> He suggested that the
> file indexing plugins be present in a separate repository. It doesn't affect
> us much, so I would like to know your opinion? Do you want it to be in a
> separate repo?
Can we please keep this on-topic. We may not like the idea, but the
reality is our distro's have particular legal requirements that they
need to meet before shipping code. Some risks they are willing to
take, others they are not, and that varies by distro. This discussion
is how best to help meet those requirements while still offering the
maximum functionality to our users who want to add the plugins.
Vishesh tells us that he is using a plugin system and just wants to
know if it needs a separate repo for the plugins. Perhaps it would
help if Vishesh provides more detail on how the the plugin system is
structured and how it differs (if any) from the way Strigi currently
does it (which is obviously already acceptable to the distros). In
particular is it possible to just install the extra plugins without a
re-compile?
You would only need to compile the plugin and install it.
I was not terribly clear earlier, my fault. I was thinking from a technical (developer) point of view. I thought it was understood that we would not have a hard dependency to ffmpeg. When I said NepomukCore depends on ffmpeg, I mean that the top level CmakeLists has the checks. That is all.
The plugin system is exactly as any other plugin based system in KDE.
Taking the wider view, can you tell us how this affects the future of
Stigi? Would I be right in saying Strigi is no longer needed in KDE,
i.e. is it deprecated, do the distro's need to install it any more,
etc?
Well, we're somewhere in the middle right now. We were just discussing this on #kde-devel.
Nepomuk will no longer depend on Strigi, but KFileMetaInfo still uses strigi. So we either keep that functionality or decide how we want to proceed. The new plugin based system has a hard link time dependency to Nepomuk-Core, so it cannot go into kdelibs. I'm not sure what we want to do.
Cheers!