Review Request 117016: Allow overriding DrKonqi lookup directories by PATH

[Alex Merry]

> On March 24, 2014, 3:41 p.m., Alex Merry wrote:
> > The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization).
> 
> Aleix Pol Gonzalez wrote:
>     Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it.
> 
> Dan Vrátil wrote:
>     I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-)
> 
> Kevin Ottens wrote:
>     Aleix, weren't you indeed planning to move drkonqi in? Any ETA?
> 
> Aleix Pol Gonzalez wrote:
>     I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important.
> 
> Dan Vrátil wrote:
>     Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1.
> 
> Aleix Pol Gonzalez wrote:
>     I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK.
>     
>     But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so.
> 
> Alex Merry wrote:
>     As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them.
> 
> Aleix Pol Gonzalez wrote:
>     I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!).
>     
>     I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin.
>     
>     In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec.

It's not unrelated.  The issue that we want to solve is installing packages in different prefixes.  The issue just goes away if drkonqi is part of kcrash.

The plugin thing sounds sensible to me.  It can go in frameworkintegration, I guess.


- Alex


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


On March 24, 2014, 12:01 p.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117016/
> -----------------------------------------------------------
> 
> (Updated March 24, 2014, 12:01 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcrash
> 
> 
> Description
> -------
> 
> Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility.
> 
> This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance.
> 
> 
> Diffs
> -----
> 
>   src/kcrash.cpp 87163cc 
> 
> Diff: https://git.reviewboard.kde.org/r/117016/diff/
> 
> 
> Testing
> -------
> 
> - Installed KCrash into /usr prefix
> - Installed drkonqi from kde-runtime master to /opt/kde5 prefix
> - started broken application
> - no "could not find drkonqi" warning anymore
> - crashed application, got drkonqi window
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140328/f59387d0/attachment.html>