Since konsole5 provides partially the same files as konsole4 there is a binary conflict between the two which means that the two cannot (or should not) be installed at the same time as you'd either end up with konsole(5) or konsole(4) in $prefix/bin/ and which one it's gonna be only depends on which source was installed last. A user does however require parts of konsole(4) to be installed to allow smooth migration from kdelibs4 to frameworks. Namely without the konsole(4) kpart the following applications will have no terminal tab: - kile - yakuake - krusader - kdevelop - dolphin (kate is supposed to get a port released as part of applications 14.12) To allow a smooth migration I therefore think that konsole(5) should either be entirely co-installable with konsole(4) or it should simply build libkonsoleprivate.so(qt4) and konsolepart.so(qt4) to allow kpart-dependent applications to not loose features. Reproducible: Always
this looks to me like a pure packaging problem. only executables collide in konsole/4 and konsole/5 clash. and it was never supposed to have 2 same apps coinstallable, no? same is also valid for e.g. gwenviewpart, etc..
That doesn't really have much to do with packaging other than some distributions having to reshuffle their stuff because of it. If I compile and install both versions from source because I need the kpart for kdevelop then I must install 4 first and 5 last, and I must not ever install 4 again or I'll have to install 5 as well. It's basically an explicit partial overwrite, which to be honest is just a mess. If I then want to uninstall 4 because all kpart apps are available with a kf5 version I get to install 5 again because 4 will remove prefix/bin/konsole from 5.
(In reply to Harald Sitter from comment #2) > If I compile and install both versions from source because I need the kpart > for kdevelop then I must install 4 first and 5 last, and I must not ever > install 4 again or I'll have to install 5 as well. why? as said, only the main binaries collide
Because I can not build only the kpart.
i don't see how is that related to coinstallability
from the subject: "or otherwise provide compatibiltiy"
comment 2 really has nothing to do IMHO with neither coinstallability nor compatibility. this only concerns those who would wont both executables: only binary clashes. wrt 2xtime build, the same is valid for e.g. khtmlpart, gvpart, okulartpart, etc... that there will be no 2 *simultaneously* provided apps (i.e. both kdelibs4 and KF5 based), is a general issue, and doesn't concerns konsole alone, but any app which is usable to outside world, or provides some bits and pieces useful to other apps. iow - this sounds like there could/should be some general consensus how to deal with this. konsole is just one example. otherwise it is really a packaging issue, or there would be a 2x time build from one source for all such apps (afaik, only kmix atm provides ability to build it in kdelibs4 and KF5 "mode" from same source)
Yes, this is to some degree a problem with wider scope than konsole. and at the same time it is not because khtmlpart is actually in frameworks and as such has no conflict, and all parts other than konsolepart are (as far as I am aware) only used by 2 applications: the providing application (okular, krita, what have you) and as a viewer component *option* in konqueror/rekonq through file type association. So, I will absolutely settle for getting this solved only for konsole, because all the other parts have no real problem... konqueror/rekonq will simply open the URL in the viewer itself rather than through the part. I feel the entire business of application provided plugin nonesense should have had some brain power thrown at it a while ago. KIO on paper suffers from the same problem.
ok, let's say konsole is the biggest victim - ark is second, as it uses kparts afaik to preview files inside archives; and will miss service menus for extract here... etc (though this example is more theoretical, as neither ark nor kde-baseapps are KF5 based in master yet; and maybe we get lucky and they both get merged in for the same release ;-)
kate's part has similarly terrible exposure kile -> katepart kdevplatform (plasmate, kdevelop) -> katepart | ktexteditor I might be a bit flaky on the details but I suppose reasonable devs use katepart through ktexteditor, so everything should have a working text editor as fallback (alas, minus the highlighting and all the fancy kate features).
I don't see a way around this other than post-fixing the binary names with a 5, so I'm in favor of doing that. With our strategy of releasing both, KDE4 and Frameworks5 version at the same time next month, this is an issue that needs solving *now*.
Kile also uses Okular kpart
Isn't all that is required *really* is that konsole(4) kpart and konsole(5) be parallel-installable? If so, providing some easy way to build/install konsole4 kpart only should be sufficient.
This should not be a problem anymore, as the migration to Frameworks 5 & Konsole on such a system is long complete.