D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment. Looking into the bug report gaves the answer: file /usr/i686-w64-mingw32/sys-root/mingw/bin/ksendbugmail.exe from install of mingw32-libKF5XmlGui5-5.26.0-3.1.noarch conflicts with file from package mingw32-kdelibs4-4.14.60-11.4.noarch For the recored: this could happens on obs, where stable releases for umbrello and kmymoney on Windows are build. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker, dfaure, ltoscano, bcooksley Cc: kde-frameworks-devel, bcooksley, dfaure, aacid, LeGast00n, cblack, michaelh, ngraham, bruns
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
dfaure requested changes to this revision. dfaure added a comment. This revision now requires changes to proceed. Herald edited subscribers, added: kde-frameworks-devel; removed: Frameworks. Ben's question was never answered... REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker, dfaure, ltoscano, bcooksley Cc: kde-frameworks-devel, bcooksley, dfaure, aacid, LeGast00n, cblack, michaelh, ngraham, bruns, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
bcooksley added a comment. From my understanding of this on Linux/FreeBSD the install destinations for these binaries are different. On Windows you should have one install prefix per application and you can't mix Qt versions in an application. So i'm not seeing how we end up with a clash here? REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker, dfaure, ltoscano, bcooksley Cc: bcooksley, dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added reviewers: ltoscano, bcooksley. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker, dfaure, ltoscano, bcooksley Cc: bcooksley, dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a reviewer: dfaure. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker, dfaure Cc: bcooksley, dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
bcooksley added a comment. In https://phabricator.kde.org/D5173#124620, @habacker wrote: > BTW: You mentioned that KF5_LIBEXEC_INSTALL_DIR is 'bin/libexec/kf5/' on Windows, Should it not be lib/libexec/kf5 ? On unix this is located in 'lib[64]/libexec/kf5 ' - why this difference ? Windows only looks in system locations (as specified in %PATH%) and the current directory of the binary for library (dll) files. Therefore on Windows *.dll files are stored in $prefix/bin/ and not $prefix/lib. As a consequence the libexec directory is also relocated to $prefix/bin/ REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: bcooksley, dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment.
> So bin isn't in %PATH%, but found relatively to the app being run?
yes
> This makes me wonder if libexec could be bin/libexec/kf5/ on Windows,
relative too.
This requires to add support for finding executables located in libexec based
on install root e.g. instead of using
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail5"));
to use something like this
QString installroot = getKF5Prefix(); // similar to what is implemented
in KDE4 (see
https://cgit.kde.org/kdelibs.git/tree/kdecore/kernel/kkernel_win.cpp?h=KDE/4.14#n97)
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), installRoot +
QStringLiteral("bin/libexec/kf5/"));
or
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), installRoot +
QStringLiteral(KF5_LIBEXEC_INSTALL_DIR));
if KF5_LIBEXEC_INSTALL_DIR is a relative path to the requested subdir based
on the install root.
> Then we could have an ECM-provided string that expands to
> CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR on Unix (i.e. absolute),
and
> KF5_LIBEXEC_INSTALL_DIR on Windows (i.e. relative).
> Wouldn't this keep the Unix/Windows differences to a minimum?
Related to install layout it would be reduce the difference, but on the
source code side you need to add detecting the install root to any code where
an executable located in libexec needs to be searched, which increases the
differences in the source code.
The complete code fragment would look like
#ifndef Q_OS_WIN32
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"));
if (command.isEmpty()) {
command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/"
KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail");
#else
QString searchPath = getKF5Prefix() +
QStringLiteral(KF5_LIBEXEC_INSTALL_DIR);
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), searchPath);
#endif
An optimization would be to call getKF5Prefix() on non Windows too, which
returns CMAKE_INSTALL_PREFIX "/". This reduced the above mentioned code to
QString searchPath = getKF5Prefix() + QStringLiteral(KF5_LIBEXEC_INSTALL_DIR);
QString command =
QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), searchPath);
BTW: You mentioned that KF5_LIBEXEC_INSTALL_DIR is 'bin/libexec/kf5/' on
Windows, Should it not be lib/libexec/kf5 ? On unix this is located in
'lib[64]/libexec/kf5 ' - why this difference ?
REPOSITORY
R263 KXmlGui
REVISION DETAIL
https://phabricator.kde.org/D5173
To: habacker
Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
dfaure added a comment. So bin isn't in %PATH%, but found relatively to the app being run? This makes me wonder if libexec could be bin/libexec/kf5/ on Windows, relative too. Then we could have an ECM-provided string that expands to CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR on Unix (i.e. absolute), and KF5_LIBEXEC_INSTALL_DIR on Windows (i.e. relative). Wouldn't this keep the Unix/Windows differences to a minimum? REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment. In any discussion about libexec related issues we keep hitting the fact that there is no standard env var for it. Maybe we need a custom one (which could then be KF5_LIBEXEC_PATH, so it won't conflict with KF6). Because every KDE application installers bundles a complete KF5/Qt5 runtime using system or user based environments are not a possible way to solve path issues. Setting something like KF5_LIBEXEC_PATH would work for one installation, but not for all other installations. Therefore in KDE4 times all path calculations are based on the runtime install path (by detecting the path of shared libraries e.g. kdelibs or dbus or executables like dbus-daemon. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment. > The question is, can you add libexec to the path (so that findExecutable works) only for kf5-based executables (so that kde4 apps don't break) ? no > If not, then your description of the problem was incorrect and this is not just about dbus-started services but about difficulties locating the libexec dir on Windows. this problem has already been solved in KF5 by installing all 'libexec' executables into bin. The remaining issue the name clash this bug describes. You may state: 'If this is a windows only problem the solve it on Windows only' - I already thought about that by wrapping all the hunks in this patch with #ifdef Q_OS_WIN32 ... #endif - would that better ? REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
dfaure added inline comments. INLINE COMMENTS > habacker wrote in kbugreport.cpp:527 > BTW: This will not work on Windows because the absolute build time install > path is used which differs in mostly cases from the runtime install path. Which is why this is just a fallback ;) The question is, can you add libexec to the path (so that findExecutable works) only for kf5-based executables (so that kde4 apps don't break) ? If not, then your description of the problem was incorrect and this is not just about dbus-started services but about difficulties locating the libexec dir on Windows. In any discussion about libexec related issues we keep hitting the fact that there is no standard env var for it. Maybe we need a custom one (which could then be KF5_LIBEXEC_PATH, so it won't conflict with KF6). REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
dfaure added a comment. Well I would accept a compromise, where dbus-started services get installed in bin on Unix as well. Which means still only two install vars and dirs: bin and libexec. With consistency between Unix and Windows about whether a given executable gets installed into bin or libexec. It's easier to remember the rule "dbus-started services go into bin" than "you need to add a '5' prefix even to libexec binaries even though they are in a kf5 subdir so it looks like this shouldn't be necessary". REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added inline comments.
INLINE COMMENTS
> kbugreport.cpp:527
> if (command.isEmpty()) {
> -command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/"
> KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail");
> +command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/"
> KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail5");
> }
BTW: This will not work on Windows because the absolute build time install path
is used which differs in mostly cases from the runtime install path.
REPOSITORY
R263 KXmlGui
REVISION DETAIL
https://phabricator.kde.org/D5173
To: habacker
Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment. I did not took a look into every location where an executable is installed into KDE_INSTALL_LIBEXECDIR_KF5, but I guess on Windows any application which may be started *only* by a KF5 provided api may be located in the libexec dir ; all other needs to stay into /bin (or in case there is no bin dir in the installation I saw in some null soft based installations like digikam) If you really want to have executables in libexec dir on Windows too a patch is required to change KDE_INSTALL_LIBEXECDIR_KF5 to xxx/libexec and to introduce a different cmake variable for installing all other executables, which points to the "bin"-dir on Windows and the same path as KDE_INSTALL_LIBEXECDIR_KF5 on other platforms. Then every occurrance of KDE_INSTALL_LIBEXECDIR_KF5 in kf5 libraries needs to be checked and replaced by this variable Adding '5' postfix to 4 executables (see https://bugs.kde.org/showdependencytree.cgi?id=373928_resolved=1) would be a more simple solution from my opinion. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
dfaure added a comment. If "findable by dbus services" is the only argument for polluting bin with libexec binaries on Windows, then it doesn't apply to *everything* in libexec, only to a handful of executables. lib64/libexec/kauth/backlighthelper lib64/libexec/kauth/discretegpuhelper lib64/libexec/kauth/fontinst lib64/libexec/kauth/fontinst_helper lib64/libexec/kauth/kalarm_helper lib64/libexec/kauth/kcmdatetimehelper lib64/libexec/kauth/kcm_kwallet_helper5 lib64/libexec/kauth/kcmsddm_authhelper lib64/libexec/kauth/ksysguardprocesslist_helper lib64/libexec/kdeconnectd lib64/libexec/kf5/kiod5 lib64/libexec/kf5/kscreen_backend_launcher lib64/libexec/ktp-auth-handler lib64/libexec/ktp-filetransfer-handler lib64/libexec/ktp-proxy lib64/libexec/ktp-text-ui Everything else can still go into libexec, no? REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: dfaure, aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker added a comment. You saw the related bug report at https://bugs.kde.org/show_bug.cgi?id=374347 ? "ksendbugmail is installed into KDE_INSTALL_LIBEXECDIR_KF5, which seems to be set on Windows to 'bin'. At KDE4 times all executables are installed in /bin to be findable by dbus services. This requirement is valid for KF5 too so it is required to install the tool with another name ksendbugmail5.exe on Windows." REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
aacid added a comment. Are you sure this is needed, they get installed in different prefixes so what's the problem? /usr/lib/kde4/libexec/ksendbugmail /usr/lib/x86_64-linux-gnu/libexec/kf5/ksendbugmail REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D5173 To: habacker Cc: aacid, #frameworks
D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.
habacker created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY The executable is now named ksendbugmail5. BUG:374347 REPOSITORY R263 KXmlGui BRANCH 374347 REVISION DETAIL https://phabricator.kde.org/D5173 AFFECTED FILES src/kbugreport.cpp src/ksendbugmail/CMakeLists.txt src/ksendbugmail/main.cpp To: habacker Cc: #frameworks
