[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdelibs-bugs
Subject:    [frameworks-kio] [Bug 353642] kio master conflicts kde-baseapps 15.08.x
From:       Harald Sitter <sitter () kde ! org>
Date:       2015-10-08 6:39:38
Message-ID: bug-353642-90985-D5Hy81Q23e () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=353642

--- Comment #2 from Harald Sitter <sitter@kde.org> ---
> Moreover, the frameworks branch of lib/konq has not been released AFAIK, and I \
> think it never will be. Nevertheless, this should be solved, but I am unable to do \
> anything about this in the next two weeks (and any change won't help before the kio \
> version is increased).

It's not the frameworks branch though. The Qt4 version, as released with 15.08,
also installs to $PREFIX/share/templates.

> The ideal solution would be to skip the installation of these files in the \
> frameworks branch of lib/konq in kde-baseapps if the installed kio version is > \
> 5.15. Thus would not have any effect until the version number us increased in kio \
> master though.

This is an approach we had for I think it was kglobacceld (moved from plasma to
framework) which still causes major headache as we need to communicate that to
distros so they don't ignore us, and then the grand majority of distros need to
go back and adjust their packaging and rebuild the binaries. 

> Note that simply removing the files from lib/konq might be dangerous because some \
> distros might package and release its frameworks branch in order to work around the \
> context menu issues that the kio commit fixes.

Yes. So. What if, and I am just throwing this out here because I only had one
cup of coffee yet, so it might be utter nonsense ;)... what if the kio
templates installed to $PREFIX/share/kio5/templates instead? kde-baseapps
(kdelibs) could potentially still be released with applications 15.12 and not
conflict with KIO since the paths are different, and lib/konq (frameworks)
could release whenever ready and depend on suitably high enough KIO version to
get the templates from KIO rather than install its own. Additionally putting it
into a kio5 dir means a kio6 (kf6) in the future will not be interfering with
the kf5 files and we won't have a conflict there.

As for distributions pulling random snapshots of libkonq, I think we are best
served ignoring this, or at least advising that building a temporary workaround
based on the KIO change is the best way for distributions to go about this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Kdelibs-bugs mailing list
Kdelibs-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdelibs-bugs


[prev in list] [next in list] [prev in thread] [next in thread]