[Nepomuk] The Nepomuk Situation

[Vishesh Handa]

I just noticed that this discussion is no longer cced to kcd.

On Thu, May 3, 2012 at 2:47 PM, Christian Mollekopf <chrigi_1 at fastmail.fm>wrote:

>
>
>  On Thu, May 3, 2012, at 02:22 PM, Vishesh Handa wrote:
>
>
>
>  On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf <chrigi_1 at fastmail.fm
> > wrote:
>
> > On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote:
> >
> > Hey everyone!
> >
> Hey Vishesh,
>
>
> Hey Christian
>
>
> Glad your tackling this, it's indeed a rather painful situation.
>
> >
> > So, we need a solution.
> >
> > The first solution -
> > * Remove nepomuk from kdelibs and kde-runtime
> > * Make nepomuk-core a compile time dependency for kdelibs
> > * Including the missing gui code into nepomuk-core
> >
> > The second solution is -
> > * nepomuk-core installs the headers in nepomuk2
> > * the library already has a different name, so there are no clashes over
> there
> > * kde-runtime/nepomuk is removed
> > * nepomuk-core is added as a dependency of kde-runtime
> >
> > The problem with the second solution is that all applications using
> Nepomuk
> will also need to depend on nepomuk-core. So far the list includes -
> Dolphin,
> KDE-pim and Telepathy (kinda)
> >
>
> I would suggest to create two repostories. One "nepomuk-core" containing
> the
> dependencies of kdelibs (respectively nepomuks core libraries), and another
> one "nepomuk2" containing the dms and possibly other stuff which depends on
> kdelibs (and in the future the required parts of kf5). That would give you
> clean dependencies without copies of code, which I think would be rather
> ugly
> (assuming that the "missing gui code" would be a copy of kdelibs code).
>
>
> I do not think this would be possible. Cause kdelibs requires parts of the
> new APIS (Datamanagent APIs), for now we have just copied some of the
> headers, and cpp files and are duplicating stuff.
>
> I would really want to avoid fragmenting nepomuk even more. Having 2
> repositories with related code is something that we want to avoid.
>
>
>  Indeed, if the code is related you don't want to split it. I suppose I
> don't really understand your two suggestions then.
>  I would just depend on nepomuk-core from kdelibs/kde-runtime (if
> necessary) and every application that uses nepomuk (if you're using it,
> depend on it).
>  I don't think you should try to keep applications from depending on stuff
> they need, because that also gives the option not to depend on it.
>
>  PS: I can't seem to reasonably answer to your html mails, neither in
> kmail nor in the webinterface.
>
>  Cheers,
>  Christian
>
>
>
>
> I don't see any problem with applications having to depend on nepomuk
> libraries when they're using it. In contrary I would welcome repositories
> which keep dependencies low, as that opens new possibilities, such as using
> the same libraries in a server environment where you don't want to pull in
> everything including X11.
>
> Cheers,
> Christian
>
> > What do you guys think?
> >
> > [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core
> > [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-
> management-service/<http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-%0Amanagement-service/>
> >
> > --
> > Vishesh Handa
> >
> >
> >
> >
> >
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>
>
>
> --
> Vishesh Handa
>
>
>
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120503/2aa706c3/attachment.htm>