nepomuk-core depends on kdelibs. So kdelibs cannot depend on nepomuk-core. We would have to get rid of those dependencies in kdelibs. But that should not be too hard.
On 05/03/2012 11:21 AM, Vishesh Handa wrote: > I just noticed that this discussion is no longer cced to kcd. > > On Thu, May 3, 2012 at 2:47 PM, Christian Mollekopf > <chrig...@fastmail.fm <mailto:chrig...@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 >> <chrig...@fastmail.fm <mailto:chrig...@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 >> nepo...@kde.org <mailto:nepo...@kde.org> >> https://mail.kde.org/mailman/listinfo/nepomuk >> >> >> >> >> -- >> Vishesh Handa >> > > > > > > -- > Vishesh Handa > > > > _______________________________________________ > Nepomuk mailing list > nepo...@kde.org > https://mail.kde.org/mailman/listinfo/nepomuk