Remove the "5" suffix from KF binary names, and provide compat symlinks in KF5
Open, Needs TriagePublic

Description

Not a complete list, but rather what I have installed on my system ls /usr/bin/*5 -1:

/usr/bin/checkXML5
/usr/bin/kbuildsycoca5
/usr/bin/kcmshell5
/usr/bin/kcookiejar5
/usr/bin/kded5
/usr/bin/kglobalaccel5
/usr/bin/kiconfinder5
/usr/bin/kioclient5
/usr/bin/kpackagetool5
/usr/bin/kquitapp5
/usr/bin/kreadconfig5
/usr/bin/ktelnetservice5
/usr/bin/ktrash5
/usr/bin/kwalletd5
/usr/bin/kwriteconfig5
/usr/bin/meinproc5
/usr/bin/preparetips5
/usr/bin/solid-hardware5

/usr/bin/kjs5 (kjs)

kinit:
/usr/bin/kdeinit5
/usr/bin/kshell5
/usr/bin/kwrapper5

/usr/bin/kdebugdialog5 (kdelibs4support)

/usr/bin/systemsettings5

kde-cli-tools:
/usr/bin/ktraderclient5
/usr/bin/kmimetypefinder5
/usr/bin/keditfiletype5
/usr/bin/kdemv5
/usr/bin/kde-open5
/usr/bin/kdecp5
/usr/bin/kstart5
/usr/bin/ksvgtopng5

kwalletmanager:
/usr/bin/kwalletmanager5

ahmadsamir renamed this task from Take care of renaming foo5 to foo6 in C++ code after branching to Take care of renaming (stuff under /usr/bin/) foo5 to foo6 in C++ code after branching.
alex added a subscriber: alex.Aug 3 2021, 7:14 PM

Aren't kinit and kjs supposed to go away?

Some stuff in plasma domain - but I don't mind :)

In T14763#261277, @alex wrote:

Aren't kinit and kjs supposed to go away?

That's why I put them in their own blocks.

Some stuff in plasma domain - but I don't mind :)

Plasma yes, but most likely used by some code in KF to launch it.

(One good side effect of making this list, I found there is a ktrash5 executable, I had no idea it existed).

alex added a comment.Aug 4 2021, 6:11 AM

Plasma yes, but most likely used by some code in KF to launch it.

But that raises the question if we can make a KF6 release if Plasma 6 is not ready yet.

Generally speaking there seem to be no plans to make Plasma5/Plasma6 co-installable. Maybe one should even consider not making the executables versioned.

In T14763#261281, @alex wrote:

Plasma yes, but most likely used by some code in KF to launch it.

But that raises the question if we can make a KF6 release if Plasma 6 is not ready yet.

Not really; an executable could still have a 5 suffix in KF6, until it's ported.

Generally speaking there seem to be no plans to make Plasma5/Plasma6 co-installable. Maybe one should even consider not making the executables versioned.

That wouldn't be ideal, from packagers point of view it would make their work harder; they would have to rename the binaries downstream (a similar issue happened/happens with Qt excutables).

alex added a comment.Aug 4 2021, 10:44 AM

That wouldn't be ideal, from packagers point of view it would make their work harder; they would have to rename the binaries downstream (a similar issue happened/happens with Qt excutables).

If systemsettings5 is the executable, but datafiles get installed in a systemsettings folder it will not make a difference if the executable is versioned or not.
See https://invent.kde.org/plasma/systemsettings/-/blob/master/app/CMakeLists.txt#L37.

they would have to rename the binaries downstream (a similar issue happened/happens with Qt excutables).

Why would packagers need to rename binaries?

In T14763#261292, @alex wrote:

If systemsettings5 is the executable, but datafiles get installed in a systemsettings folder it will not make a difference if the executable is versioned or not.
See https://invent.kde.org/plasma/systemsettings/-/blob/master/app/CMakeLists.txt#L37.

Good point; I don't know how they handle that.

they would have to rename the binaries downstream (a similar issue happened/happens with Qt excutables).

Why would packagers need to rename binaries?

Because they need to make Qt5 and Qt6 co-installable, because it's never happened that when you switch from one major version to the next one, all your apps have been ported already (or at all in some cases), the same goes for KDE apps/executables. :)

alex added a comment.Aug 4 2021, 11:37 AM

The way I understand it packagers should just update from Plasma5 to Plasma 6 once it is ready.

When I asked why systemsettings is a versioned executable it was said that it was due to historical reasons.

Because they need to make Qt5 and Qt6 co-installable

In the plasma cases the executables would "just" be executables and not part of a lib. But yeah, for frameworks it should of course be co-installable.

dfaure added a subscriber: dfaure.Oct 4 2021, 3:36 PM

kde-cli-tools: we all agreed in today's call that the best course of action is to remove the '5' (for compatiblity, we should still provide the '5' name as a symlink to the versionless binary). And for KF6, we'll stop installing those symlinks. The reason this is possible now (while it wasn't before) is that by forking slaves instead of talking to klauncher, we don't need to use the same KF version as the running environment anymore.

alex added a comment.EditedOct 4 2021, 7:03 PM

But kcmshell should be moved to KCMUtils. We could just rename it to kcmshell6 since it is then part of frameworks.

Do the other tools from kde-cli-tools matter in the frameworks context?

alex added a comment.Oct 4 2021, 7:04 PM
/usr/bin/preparetips5

Should be obsolete with T11586

dfaure added a comment.Oct 4 2021, 7:49 PM

Do the other tools k´fron kde-cli-tools matter in the frameworks context?

Not exactly sure what you mean. But whether kdecp is going to use KIO5 or KIO6 makes no difference to the user; same for all of the others in that list.

krop added a subscriber: krop.Oct 5 2021, 7:09 AM
In T14763#261292, @alex wrote:

If systemsettings5 is the executable, but datafiles get installed in a systemsettings folder it will not make a difference if the executable is versioned or not.
See https://invent.kde.org/plasma/systemsettings/-/blob/master/app/CMakeLists.txt#L37.

Good point; I don't know how they handle that.

That's not really an issue as long as the code doesn't assume the default location cannot be changed.
this example is not the best one :) KDE_INSTALL_KXMLGUI5DIR is already versioned in ECM. Data files is not, look in /usr/share.

We have two ways to handle things:

  • Change the install location
  • Declare 5 and 6 versions not-coinstallable. We won't do that for libraries but for applications.

they would have to rename the binaries downstream (a similar issue happened/happens with Qt excutables).

Why would packagers need to rename binaries?

Because they need to make Qt5 and Qt6 co-installable, because it's never happened that when you switch from one major version to the next one, all your apps have been ported already (or at all in some cases), the same goes for KDE apps/executables. :)

That's not an issue anymore since Qt 6.1. The build system has two variables, one for binaries (INSTALL_BINDIR and another one for versioned symlinks (INSTALL_PUBLICBINDIR)

@krop thanks for the info and insights; looks like Qt are making good use of CMake.

ahmadsamir renamed this task from Take care of renaming (stuff under /usr/bin/) foo5 to foo6 in C++ code after branching to Remove the "5" suffix from KF binary names, and provide compat symlinks in KF5.Oct 26 2021, 9:33 PM

But will the unversioned executables not conflict with kdelibs 4 or 3 applications? At least some of those executables were part of the Plasma 4 kde-runtime which, as the name says, is required by some kdelibs 4 applications at runtime.

Urgh, does anyone still ship kdelibs4 or kdelibs3?

Fedora still ships both, and I still use some unported legacy applications using either.