Install kioslave.exe as kioslave5.exe under Windows
Needs ReviewPublic

Authored by habacker on Dec 18 2018, 10:11 AM.

Details

Reviewers
lbeltrame
vonreth
Group Reviewers
Frameworks
Summary

Under Windows, utilities stored in the 'libexec' installation path are
installed in the executable path. They usually have a '5' suffix e.g.
kcookiejar5, ktelnetservices5, ktrash5.

kioslave is used by kio internally to start io slaves using klauncher.
This patch requires a similar patch to be applied to klauncher
(repo kinit, see https://phabricator.kde.org/D17719)

FIXED-IN:5.54.0
BUG:377687

Diff Detail

Repository
R241 KIO
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 6232
Build 6250: arc lint + arc unit
habacker created this revision.Dec 18 2018, 10:11 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptDec 18 2018, 10:11 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
habacker requested review of this revision.Dec 18 2018, 10:11 AM
lbeltrame added a subscriber: lbeltrame.EditedDec 18 2018, 10:27 AM

At this point, I'd rather give my -1 to this. The 4.x kdelibs stack is *long* unmaintained, as well as Qt. What are real, compelling reasons to do this?

EDIT: I know it's for Windows, but with the recent work with the binary-factory and what not, there are even less reasons to do so there.

lbeltrame requested changes to this revision.Dec 18 2018, 10:28 AM
lbeltrame added a reviewer: Frameworks.
This revision now requires changes to proceed.Dec 18 2018, 10:28 AM

At this point, I'd rather give my -1 to this. The 4.x kdelibs stack is *long* unmaintained, as well as Qt. What are real, compelling reasons to do this?

EDIT: I know it's for Windows, but with the recent work with the binary-factory and what not, there are even less reasons to do so there.

umbrello from binary factory is far from been production ready. Windows releases are made from the KDE4 branch. See for example https://phabricator.kde.org/T7659

umbrello from binary factory is far from been production ready. Windows releases are made from the KDE4 branch. See for example https://phabricator.kde.org/T7659

I would argue this is more of umbrello's problem to keep on supporting kdelibs 4.x and KF5 at the same time than anything else.

That said, let's hear the opinion of someone else as well.

I see no reason for this. Having a KF5 and kde 4 in the path sounds like a bad idea in general.
Is this for cygwin or something like that?

On a recent opensuse Leap 42.3 or 15.x system there is

/usr/lib64/kde4/libexec/kioslave
/usr/lib64/libexec/kf5/kioslave

because the distribution provides kdelibs4 and kio packages. it only does not conflict because the executables are located in different directories because they are installed in 'libexecdir'. On Windows libexecdir points to the regular bin dir, which results into a conflict. The conflict need to be fixed by choosing a different name, as it is done also with many helper tools like meinproc4, meinproc5

$ ls /usr/bin/*5 | wc -l
73
$ls /usr/bin/*4 | wc -l
46

This comment was removed by habacker.
lbeltrame added a comment.EditedDec 18 2018, 12:33 PM

On a recent opensuse Leap 42.3 or 15.x system there is

/usr/lib64/kde4/libexec/kioslave
/usr/lib64/libexec/kf5/kioslave

As a packager of KDE software for said distribution, this is just something vestigial due to the kdelibs4.x -> KF5 code, back then when KF5 ported software was the minority. Nowadays KF5 software obsoletes (=replaces) the equivalent kdelibs 4.x variants for most packages.

Thus, at this point in time, such a change does not make sense to me. If you want to push this forward I suggest you find another example aside umbrello to use.

On a recent opensuse Leap 42.3 or 15.x system there is

/usr/lib64/kde4/libexec/kioslave
/usr/lib64/libexec/kf5/kioslave

because the distribution provides kdelibs4 and kio packages. it only does not conflict because the executables are located in different directories because they are installed in 'libexecdir'. On Windows libexecdir points to the regular bin dir, which results into a conflict. The conflict need to be fixed by choosing a different name, as it is done also with many helper tools like meinproc4, meinproc5

$ ls /usr/bin/*5 | wc -l
73
$ls /usr/bin/*4 | wc -l
46

I don't think I get your point.
So you want to install KDE4 and KF5 into the same directory on Windows?

This comment was removed by habacker.

umbrello from binary factory is far from been production ready. Windows releases are made from the KDE4 branch. See for example https://phabricator.kde.org/T7659

I would argue this is more of umbrello's problem to keep on supporting kdelibs 4.x and KF5 at the same time than anything else.

Agreed. Why not put in the effort to port it fully to KF5 instead?

I think this is unrelated - this request is to fix an issue with an available package on a distribution, so can anyone accept this ?

I think this is unrelated - this request is to fix an issue with an available package on a distribution, so can anyone accept this ?

I'd argue that the problem is with your distribution. Everybody still shipping qt4 is on its own anyway, seeing that it's not possible to upstream patches (and there are quite a few needed to keep it building) as the git repo is locked down. And I'm pretty sure this patch breaks at least one other framework. Additionally there might be future maintenance costs, so I see no reason to flog a dead horse and penalize everybody else for it.

I think this is unrelated - this request is to fix an issue with an available package on a distribution, so can anyone accept this ?

I'd argue that the problem is with your distribution. Everybody still shipping qt4 is on its own anyway, seeing that it's not possible to

It's not even there. I co-maintain the KF5 and Applications packages in openSUSE and I would refuse outright such patches downstream (also, there are no bug reports downstream either on these possible issues). For the rest, what @heikobecker said is spot on. We don't want extra maintenance to fix *one* edge case.

I'd argue that the problem is with your distribution.

It is designed in ECM to install mentioned helpers on windows (which are cross compiled packages on obs) in main executable install dir.

$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/bin/kioslave.exe 
mingw32-kdelibs4-4.14.60-30.27.noarch
$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/bin/kioslave.exe 
mingw32-kio-5.47.0-11.28.noarch

Everybody still shipping qt4 is on its own anyway,

Unfortunally yes, for example https://build.opensuse.org/package/show/windows%3Amingw%3Awin32/mingw32-kdelibs4, but this is unrelated, we are about talking about a patch for KF5, not qt4.

seeing that it's not possible to upstream patches (and there are quite a few needed to keep it building) as the git repo is locked down.

It needs someone to take over maintenance of kdelibs.

And I'm pretty sure this patch breaks at least one other framework.

no, it is only used in kio internally by klauncher to start io slaves.

Additionally there might be future maintenance costs,

no, it simply follows the name style other kio executables installed in normal 'bin' dir already have e.g kcookiejar5, ktelnetservices5, ktrash5.

so I see no reason to flog a dead horse and penalize everybody else for it.

In recent years, of the 104 KDE4 applications for Windows (https://community.kde.org/Windows/Releases/4.10.2), only 7 are available for KF5 (https://community.kde.org/Windows, minus the stable versions of Umbrello and KMymoney that are still on KDE4). KDE4 will probably stay as a base for a while.

$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/bin/kioslave.exe 
mingw32-kdelibs4-4.14.60-30.27.noarch
$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/bin/kioslave.exe 
mingw32-kio-5.47.0-11.28.noarch

For the record, those packages aren't shipped officially by the distribution you are using.

seeing that it's not possible to upstream patches (and there are quite a few needed to keep it building) as the git repo is locked down.

It needs someone to take over maintenance of kdelibs.

No. You need to get over the fact that kdelibs4 development is *done* and deal, period. Qt4 is EOL, kdelibs4 is EOL. It is time to move on.

In recent years, of the 104 KDE4 applications for Windows (https://community.kde.org/Windows/Releases/4.10.2), only 7 are available for KF5 (https://community.kde.org/Windows, minus the stable versions of Umbrello and KMymoney that are still on KDE4). KDE4 will probably stay as a base for a while.

Why not joining the effort of the people that are working to get those applications on Windows, rather than relying on unmaintained software? By distributing Qt 4.x based software we are exposing users to risks, given it is completely unmaintained.

Yes there are more 'nightly' releases, which is a good thing :-),

but there are only about 6 'release' versions

https://binary-factory.kde.org/view/Windows%2064-bit/ : 5
https://binary-factory.kde.org/view/Windows%2032-bit/ : 6

and KMyMoney 'release' version is marked as 'Preview Release' (see https://kmymoney.org/)

no, it is only used in kio internally by klauncher to start io slaves.

at least kinit disagrees:

src/klauncher/klauncher.cpp:1021        arg_list.prepend(QLatin1String("kioslave"));
vonreth added a comment.EditedDec 21 2018, 9:55 AM

In kde4 we had 104 unmaintained untested applications.
The 6 now are much better supported, in general we only add applications to binary factory if a project asks for it and maintains it for some degree.

habacker added a comment.EditedDec 21 2018, 9:58 AM

Why not joining the effort of the people that are working to get those applications on Windows,

You did not get the point. If there is anything left over besides the time I have to maintain the KDE applications and libraries, I go through this list (https://bugs.kde.org/showdependencytree.cgi?id=373932&hide_resolved=1) and try to fix the related issue or check if some else has fixed it. The list has already been reduced from 66 to 28.

In kde4 we had 104 unmaintained untested applications.
The 6 now are much better supported, in general we only add applications to binary factory if a project asks for it and maintains it for some degree.

no, it is only used in kio internally by klauncher to start io slaves.

at least kinit disagrees:

src/klauncher/klauncher.cpp:1021        arg_list.prepend(QLatin1String("kioslave"));

Thanks for this pointer, which is one of the major differences to KDE4 and makes it sometime hard to follow. In KDE4 kinit is also located in the same repo.

and try to fix the related issue or check if some else has fixed it.

See this https://bugs.kde.org/show_bug.cgi?id=380139 as example. The different Qt installation layout depending on the platform is a nightmare for cross-platform support and ties up resources that are no longer available for more important things. Making cross compiled packaged on obs for example is mostly a simple copy and replace of specific variables (for example that shared files are located in bin dir, not in lib). Converting to the complete different Qt 5 path layout results into much more work without any benefit.

habacker updated this revision to Diff 47944.Dec 21 2018, 10:36 AM
habacker retitled this revision from Install kioslave as kioslave5 on Windows to Install kioslave.exe as kioslave5.exe under Windows.
habacker edited the summary of this revision. (Show Details)
  • fix clients of kioslave

I would still suggest you get your stuff done with the binary factory and not on the OBS simply because then KDE as a whole can benefit from it. Not doing so will make sure that Windows and other platform-specific issues will never be found.

See this https://bugs.kde.org/show_bug.cgi?id=380139 as example. The different Qt installation layout depending on the platform is a nightmare for cross-platform support and ties up resources that are no longer available for more important things.

Here you can an actual example - https://phabricator.kde.org/T10207

See this https://bugs.kde.org/show_bug.cgi?id=380139 as example. The different Qt installation layout depending on the platform is a nightmare for cross-platform support and ties up resources that are no longer available for more important things.

Here you can an actual example - https://phabricator.kde.org/T10207

This issue is related to your configuration of the blacklist.