I’ve run into issues lately where software is expecting an executable to be available but cannot find it on my system. On checking I discover the expected file exists but is named with a ‘6’ at the end (i.e. qdbus is now qdbus6 - or qtpaths is now qtpaths6).
What is the rationale for this happening? Its obviously purposeful. Is it so older applications that used qdbus purposefully fail as the new version isn’t backwards compatible? That’s the only reason I can think of for doing this.
This is the general practice to indicate a Qt6 package rather than Qt5, as the transition from Qt5 <=> Qt6 can potentially take quite a while. This is an industry-wide practice to differentiate between the two – it was the same for Qt4 <=> Qt5, Qt3 <=> Qt6, and so on.
If the applications in question were sourced via the AUR, it’s possible that those are not yet updated by their respective maintainers. It is also possible that you have not rebuilt them, as is the expected practice after the usual sync/update.
Not knowing the state of your system or whether you maintain your system according to general recommendations, it’s also possible that you are in an unsupported state, in which case it’s very difficult for others to diagnose.
It still doesn’t quite make sense. If its standard across version releases then why do many packages/software/widgets etc use specifically qdbus for example and not whatever qdbus version was available at the time (qdbus4, qdbus5, qdbus6, etc)?
Is there supposed to be aliases or symlinks from the generic version to the numbered version?
A couple have but I contacted the devs and they updated them immediately. The other areas I’ve noticed it are in KDE widgets, and again they have been updated promptly once reported.
But this seems like something we were taught not to do when coding (creating version specific executables). Its creating forced redundancy and increasing code upkeep (perhaps that’s by design for some reason but that’s what I’d like to understand).
This would be one way to explain it. As is usually the case during a transition period between Qt versions, there might be one package that depends on the Qt5 version of a given dependency, and another that that depends on the Qt.
So, in that case there might be both versions available in the system to cater for each scenario. Eventually packages relying on Qt5 become less and less as packages requiring Qt6 replace those depending on Qt5.
A question really needs asking on case by case basis, while specifying the package concerned and providing system information to help identify which version of a package may be relevant.
You can’t have two files with identical locations and names, so the newer one gets a number added. That way you can have both versions installed and software that hasn’t been updated yet should still work.
Specifically on account of qt- and KDE related stuff, at first the “6” was added to denote that this was the newer version, aiming at Plasma 6. Then, as the pre-release Plasma 6 became mainstream and more stuff was being ported to qt6, the qt5 and Plasma 5 components were given a “5” suffix. And then, when Plasma 6 was officially released, the “6” suffix was dropped from most components while the “5” suffix remained for the older stuff.
But not all packagers and add-on developers have bothered to complete the transition, and so there still are packages with a “6” suffix going round.
The KDE developers upstream have worked around this by making the “-6” versions an alias to the non-numbered executables in scenarios where both a “5” and a “6” are present for the same executable — the “6” version will then be the same as the non-numbered version, and the “5” version will explicitly invoke the qt5 variant.
But third-party developers — which is pretty much all of the KDE-related stuff in the AUR — have not all followed through with that yet.
So if I’m understanding this correctly and in an ideal world a fresh manual system install with say Qt6 only would have executables without the version number, like qdbus. But for a distribution like Arch or Manjaro where at least for a period of time you need to provide both Qt5 and Qt6, it is up to the distribution maintainers to provide symlinks to non-versioned executables?
No, not yet. It would be the same as it is in an already installed system.
Only once all of the still remaining qt5-based stuff for which there is as yet no qt6 version available has been properly renamed with a “5” suffix by the packagers — and please do bear in mind that we take most of our packages from Arch without modification — only then can the packagers omit the “6” suffix from the newer packages.
But you don’t have to worry about it, because updating your system will gradually do away with the “6” suffixes as more and more qt5 stuff is being replaced by qt6 versions. It just takes a bit of time.
Well, no, KDE themselves are also already including the links — I have not checked whether they be symlinks or hard-links.
All distributions with environments based on Qt will be subject to similar constraints during a major upheaval that transitioning from major Qt versions brings – those with KDE are only the most obvious examples – the phenomenon isn’t limited to Arch or Arch-based distributions.
A point-release type distribution, however, does have the luxury of performing these major changes spread out over major version changes of the OS.
Whereas, with a so-called rolling-release model, there is little option than to deliver said changes in increments, as they are received from upstream.
What is expected of 3rd party devs then (or even if I’m writing a script to do something) when it comes to utilising these commands? If there’s no constant name for a tool are scripts/apps supposed to employ techniques to determine the name of a tool before using it?
A stupid but illustrative example:
If ls used the same convention do all my scripts need to iterate through the possible versions until it finds the latest? ie. ls1 > ls2 > ls3 etc
I’m possibly missing something still but in my mind having this naming convention doesn’t solve any problem, it just moves it elsewhere and makes it someone elses problem (distributions, devs or end user).
Oh, another tool that just came to mind (I couldn’t remember it earlier) that is using a similar naming convention is KDE balooctl - named balooctl6 on my machine. So it’s not just Qt doing it.
As I said, the KDE developers themselves are doing it, and specifically so because there are still instances of the qt5 variant being used, and they may be dependencies of some older software someone has installed, given that this older software hasn’t been ported to Plasma 6 yet.