[Kde-pim] Review Request 116839: akonadi: skip nepomuk feeder agent if baloo indexer is present

[David Faure]

> On March 16, 2014, 5:54 p.m., Kevin Krammer wrote:
> > server/control/agentmanager.cpp, line 523
> > <https://git.reviewboard.kde.org/r/116839/diff/1/?file=254517#file254517line523>
> >
> >     that is quite a hack
> >     Akonadi server stuff should not be hardcoding such things.
> >     Can't you set XDG_DATA_DIRS to not include /usr/share?
> 
> David Faure wrote:
>     No, I want to be able to use firefox, openoffice etc....
>     
>     Surely I can't be the only one compiling KDE into its own prefix while having a distro KDE --- and having /usr/share in XDG_DATA_DIRS to get everything else in my KDE session.
>     
>     (The same problem would happen to people who install into the same custom builddir while upgrading KDE, too, unlike my inst/kde4.13 prefix)
>     
>     I know akonadi shouldn't know about these agents in theory, but it's the only place where this can go, isn't it?
>     I can't see what harm this actually creates in practice. The alternative is some sort of config file based agent exclusion... but by the time baloo's agent starts it might be too late.
>     
>     Note that the same happened when nepomuk_{email,contact,calendar}_feeder got merged into a single feeder. For a while I had all four running because of such a migration issue, so this isn't a one-time issue and might happen again.
> 
> Kevin Krammer wrote:
>     well, it is only temporary, we need to remember to revert this.
>     
>     I really don't see the problem with XDG_DATA_DIRS though. I have a whole set of different environment variable values for KDE master (actually one set per branch):
>     KDEDIRS, XDG_DATA_DIRS, KDEHOME, KDETMP, KDEVARTMP, XDG_DATA_HOME, XDG_CONFIG_HOME
>     Even running that in a separate user account.
>     
>     Never had any problem with firefox or openoffice, etc.
>     
>     If we really need all those hacks (I think we still have some other KDE specific hack in there somewhere) then we should have a KDE branch that rebased on master automatically.
> 
> David Faure wrote:
>     Sure you can start firefox etc. from a command line, but they don't appear in your KDE menu, and only the executable shows up in krunner, not the .desktop file. And you have to install shared-mime-info into your prefix as well.
>     Both setups are certainly more or less valid in their own way, I just want to fix the case of /usr/share in XDG_DATA_DIRS, since it works for everything else apart from this.
>     
>     My idea for a clean fix would be: akonadi_control reading XDG_CONFIG_DIRS/akonadi/disabled-agents.d/* and skipping the names listed there (maybe empty file is enough, we can get this from the filename), and baloo installing a "nepomukfeederagent" file there.
>     
>     Slightly more work, but if that's what it takes :)
>     
>     I disagree about the KDE branch idea, it seems creating pain forever for no good reason (if someone uses akonadi without these kde agents, why would they care about the additional if that never matches....). Sorry for being pragmatic :)
> 
> Kevin Krammer wrote:
>     So the nepomuk feeder is started because its .desktop file from /usr/share is found and the agent has capability Autostart, right?
>     Why not add the .desktop file to XDG_DATA_HOME and remove the autostart capability?
>     
>     I just don't see this as a very good precendence, patching upstream code to deal with a single downstream's "issue".
>     
>     I am not getting the firefox thing at all. My KDE menu, together with the rest of the workspace, is not affected by any test specific environment at all.
>     Do you accidentally run kdeinit in the changed environment?

Ah! This is where our misunderstanding comes from. /d/kde/inst/4.13 is not my test environment for running a single app in a distro workspace; I actually boot into that full KDE workspace.

So, if that setup doesn't have /usr/share in XDG_DATA_DIRS, then all the non-kde apps will be missing from the workspace (menu, krunner etc.) completely.

And yes of course there are local solutions (uninstalling some distro packages, adding a .desktop file in XDG_DATA_HOME...) -- but I want to fix it so that other devs with a similar setup don't have to lose time hitting that issue.

The upstream/downstream cleanliness issue can be fixed with my disabled-agents.d/* solution, then there's no nepomuk-specific hack in akonadicontrol itself, just a generic mechanism for disabling obsolete autostarted agents which might still be around.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116839/#review53082
-----------------------------------------------------------


On March 16, 2014, 5:36 p.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116839/
> -----------------------------------------------------------
> 
> (Updated March 16, 2014, 5:36 p.m.)
> 
> 
> Review request for Akonadi and Dan Vrátil.
> 
> 
> Repository: akonadi
> 
> 
> Description
> -------
> 
> akonadi: skip nepomuk feeder agent if baloo indexer is present
> 
> On my system nepomuk feeder was found in /usr/share/akonadi/agents
> and baloo was found in /d/kde/inst/kde4.13/share/akonadi/agents,
> so nepomuk feeder was started even though it's not part of 4.13, and it
> crashed, got restarted, crashed...
> 
> 
> Diffs
> -----
> 
>   server/control/agentmanager.cpp ab383577f6ab6c22c18b0bdff75f21661544e1c0 
> 
> Diff: https://git.reviewboard.kde.org/r/116839/diff/
> 
> 
> Testing
> -------
> 
> restarted akonadi, saw debug line, nepomuk feeder agent not started.
> 
> 
> Thanks,
> 
> David Faure
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/