Review Request 115602: Rename kactivitymanagerd

[Ivan Čukić]

> On Feb. 9, 2014, 7:12 p.m., Ivan Čukić wrote:
> > This is not something I'd give a green light for.
> > 
> > ActivityManager/KF5 is a drop-in replacement for the current one. They should *not* be installed side-by-side.
> > 
> >
> 
> Michael Palimaka wrote:
>     kactivitymanagerd might be drop in, but the rest of the framework is not. Any consumers that are not ported to KF5 will need to be dropped by packagers if it's not coinstallable.
> 
> Ivan Čukić wrote:
>     The library is co-installable. And the old clients will continue working fine.
>     
>     I don't want someone starting a libkactivities/kf5 client with a kactivitymanagerd/kf4
>     
>     I would accept porting the KACTIVITIES_LIBRARY_ONLY build option from the kf5 branch to kf4 version.
> 
> Michael Palimaka wrote:
>     Are you suggesting to ship kactivitymanagerd in KF5 package only, and have kactivities consumers depend on both kactivities 4 and 5?
> 
> Hrvoje Senjan wrote:
>     Ivan, we (distros) cannot make 'LTS' workspace depened on unreleased code, but we would like to provide both kactivities4 and kf5 version to users. As said, at least the most used clients, work with this patch without further adjusting on their side.

This might not be clear: libkactivities/5 *needs* kactivitymanagerd/5

--

When we get the next workspace and all, Qt4/KDElibs4 clients will require libkactivities/4, Qt5/KF5 clients will require libkactivities/5. And kamd/qt5 will be the only choice.

In the transition period, the packagers can easily create a meta-package called kactivitymanager that depends on either 4 or 5 (with those versions mutually exclusive), and libkactivities/qt4 would depend on that one. libkactivities/qt5 would depend on kactivitymanager-kf5.

@Hrvoje

I do get that. But, if you want kactivities5 clients, you *need* the kactivities5 service, and thus you need the unreleased code. And you get the problems of config files not being converted etc.

With that said, the packagers can use this patch if they want to. That way, if somebody reports bugs due to the library being newer than the service (the new library uses added apis), I can freely mark them as downstream.

Or you can install the unreleased things in a different prefix (like it was usually done for kde4 while it was in development) to tell the user 'this is not ready'.

Still, I'd rather have the situation above, all relevant distros have package management systems that can handle things like these.


- Ivan


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


On Feb. 9, 2014, 6:45 p.m., Hrvoje Senjan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115602/
> -----------------------------------------------------------
> 
> (Updated Feb. 9, 2014, 6:45 p.m.)
> 
> 
> Review request for KDE Frameworks and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> -------
> 
> ...so it can co-exists with kactivities4 in the same prefix
> 
> 
> Diffs
> -----
> 
>   src/lib/core/manager_p.cpp 57f60be 
>   src/service/CMakeLists.txt 348f8a3 
>   src/service/files/kactivitymanagerd.desktop ce68a49 
>   tests/core/Process.cpp b6279d0 
> 
> Diff: https://git.reviewboard.kde.org/r/115602/diff/
> 
> 
> Testing
> -------
> 
> Both Plasma1 and Next ran fine with this patch and withouth kactivitymanagerd(4) installed. Haven't tested the case when they are both installed.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140209/703709a6/attachment-0001.html>