Can confirm this exists. Will add it to our tracker.

https://forge.fedoraproject.org/kde/tracker/issues/709

This bug now means that most KDE apps can't be installed from Discover on Fedora 44. An up-to-date F44 has Qt 6.11, but Discover only sees the packages in the `fedora` repo which require Qt 6.10 - it can't see the Qt 6.11-compatible packages in `updates`.

See: https://discussion.fedoraproject.org/t/kde-discover-transaction-failure-on-certain-applications/201325/12

Ever since opening this bug report i've tested some things and found out that:
- This bug only happens with KDE Discover
  - PackageKit's CLI works fine
  - GNOME Software works fine
- Only affects specific repositories
  - Fedora repos are affected by it
  - RPM Fusion isn't affected by it
  - Terra PKG is affected by it
  - COPR repos seem to not be affect by it

Shouldn' t this be considered a blocker bug for F45 under the "default application functionality" criteria?

I did a test on a F45 VM, I fully upgraded the VM with all the packages from updates-testing, which is permantently enabled on the VM, and then I tried to install chromium, which is available on the updates-testing repo, and it installed the version from the fedora repo instead.

btw, me and the previous user are the same. I don' t remember why I have two bugzilla accounts and I mistankely logged in with the other one lol.

Proposed as a Blocker and Freeze Exception for 45-final by Fedora user carlis using the blocker tracking app because:

 Violates "default application functionality" criteria. This bug will eventually lead to Discover not being able to install some applications at all, like it's happening right now on F44.

Thanks for the report. We use VERIFIED to mean "verified fixed", so setting back to ASSIGNED.

AGREED AcceptedFinalBlocker

Discussed at the 2026-10-19 (blocker / freeze exception) review meeting:

This is accepted as a violation of Beta criterion 'The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)'. KDE is a release-blocking desktop and we hold this behavior is not 'appropriate'.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-10-19/f45-blocker-review.2026-10-19-16.00.log.txt

Additional sighting from Fedora 44 KDE, and a worse outcome than the transaction failure mentioned in comment 3: here the transaction did not fail, it silently downgraded large parts of the system instead.

On 2026-10-02 I installed Haruna via Discover. The PackageKit journal shows the install-packages transaction requesting haruna;1.7.1-1.fc44;x86_64;fedora, although haruna-1.8.1-1.fc44 was available in updates. haruna 1.7.1 requires libQt6Qml.so.6(Qt_6.10_PRIVATE_API), while Qt 6.11.2 was installed. The resulting dnf transaction installed 11 packages and downgraded 277 to the fedora repo versions: the entire Qt 6 stack (6.11.2 -> 6.10.2), KF6, Plasma 6.6.4, kwin, spectacle, etc. Discover showed no warning; PackageKit logged the downgrades as "updating".

A manual "dnf upgrade --refresh" a few minutes later restored everything and pulled haruna 1.8.1 (Qt_6.11_PRIVATE_API).

So besides picking the wrong NEVRA, an install from Discover can downgrade hundreds of packages without asking for confirmation. I can attach the "dnf history info" output if useful.

I just tested the rc 1.1 KDE iso (https://kojipkgs.fedoraproject.org/compose/45/Fedora-45-20261017.0/compose/KDE/x86_64/iso/Fedora-KDE-Desktop-Live-45-1.1.x86_64.iso), intalled fine, then, using Discover, installed Chromium (fedora 45 rpm stable version 154.0.8037.97-1), after that rebooted and enabled the testing repo using discover GUI, and see all the updates it found, including new chromium-155.0.8059.84-1.fc45.
Update runned normally as expected.All packages updated to the new ones in testing.

OK, I've more or less figured this one out. Here's my debug diff:

--- a/libdiscover/backends/PackageKitBackend/PackageKitResource.cpp
+++ b/libdiscover/backends/PackageKitBackend/PackageKitResource.cpp
@@ -72,7 +72,13 @@ QString PackageKitResource::availablePackageId() const
 
     const auto it = m_packages.constFind(PackageKit::Transaction::InfoAvailable);
     if (it != m_packages.constEnd()) {
-        return it->first();
+        auto first = it->first();
+        auto last = it->last();
+        QString fversion = PackageKit::Daemon::packageVersion(first);
+        QString lversion = PackageKit::Daemon::packageVersion(last);
+        qWarning() << "XXX First Version:" << fversion;
+        qWarning() << "XXX Last Version:" << lversion;
+        return first;
     }
     return installedPackageId();
 }
diff --git a/libdiscover/backends/PackageKitBackend/PackageKitResource.h b/libdiscover/backends/PackageKitBackend/PackageKitResource.h
index 534ce98f2..209388ba7 100644
--- a/libdiscover/backends/PackageKitBackend/PackageKitResource.h
+++ b/libdiscover/backends/PackageKitBackend/PackageKitResource.h
@@ -138,6 +138,11 @@ private:
             return !archPkgIds.isEmpty() ? archPkgIds.first() : nonarchPkgIds.first();
         }
 
+        QString last() const
+        {
+            return !archPkgIds.isEmpty() ? archPkgIds.last() : nonarchPkgIds.last();
+        }
+
         bool isEmpty() const
         {
             return archPkgIds.isEmpty() && nonarchPkgIds.isEmpty();

and here's what it tells us:

Oct 19 16:19:30 fedora plasma-discover[1956]: XXX First Version: "154.0.8037.97-1.fc45"
Oct 19 16:19:30 fedora plasma-discover[1956]: XXX Last Version: "155.0.8059.84-1.fc45"

To summarize, PackageKitResource has this `m_packages` map which has PackageKit::Transaction::Info keys, and values as a custom struct called 'Ids' which contains a couple of vectors, archPkgIds and nonarchPkgIds. The relevant Info instances are InfoAvailable and InfoInstalled. So for each package name you have this sort of little table telling you "for this package name, we have <these package IDs> available and <these package IDs> installed". It gets populated by the backend...somehow; I haven't plumbed out *how* yet exactly. The custom struct also has some methods (that might not be the right word, sorry, I'm a Python guy): first() and isEmpty(). first() returns the first entry in the archPkgsIds vector if it's populated, or else the first entry in the nonarchPkgIds vector.

In AppPackageKitResource.cpp there's `AppPackageKitResource::versionString()` which is just:

QString AppPackageKitResource::versionString()
{
    return isInstalled() ? installedVersion() : availableVersion();
}

and this is what's used for populating the visible UI, over in ApplicationPageFullComponent.qml:

            // Version
            QQC2.Label {
                id: appVersionLabel
                Layout.alignment: Qt.AlignRight | Qt.AlignTop
                text: i18nc("@info", "Version:")
                visible: fullComponent.application.versionString.length > 0
            }

            QQC2.Label {
                Layout.maximumWidth: Math.ceil(implicitWidth)
                Layout.fillWidth: true
                wrapMode: Text.Wrap
                maximumLineCount: 2
                elide: Text.ElideRight
                text: fullComponent.application.versionString
                visible: fullComponent.application.versionString.length > 0
            }

availableVersion is derived from availablePackageId in PackageKitResource:

QString PackageKitResource::availableVersion() const
{
    return PackageKit::Daemon::packageVersion(availablePackageId());
}

and availablePackageId is taken from this m_packages map:

QString PackageKitResource::availablePackageId() const
{
    // First we check if it's upgradeable and use this version to display
    const QSet<QString> pkgids = backend()->upgradeablePackageId(this);
    if (!pkgids.isEmpty()) {
        return *pkgids.constBegin();
    }

    const auto it = m_packages.constFind(PackageKit::Transaction::InfoAvailable);
    if (it != m_packages.constEnd()) {
        return it->first();
    }
    return installedPackageId();
}

We hit the middle path, on this specific flow. As you can see, we basically just look for the InfoAvailable entry in m_packages and then return the id of the "first" package in it. My patch logs the version of the "first" package ID and also the version of the "last" package ID. As you can see from the log messages, the problem is that, at least in this case, the *oldest* available version is the "first" one. The *newest* available version is the *last* one. I don't know if this maybe changed recently, somehow - I'll have to track out exactly how m_packages gets populated, to figure that out. But it seems like bad practice, anyway, to just *assume* that any particular entry in the vector is the "best" available version of the package. It seems like instead we should read the versions of each entry in the vector and return the highest?

I believe availablePackageId is also used as the thing that gets installed, over in PKTransaction:

void PKTransaction::trigger(PackageKit::Transaction::TransactionFlags flags)
{
...
        switch (role()) {
        case Transaction::ChangeAddonsRole:
        case Transaction::InstallRole: {
            const auto ids = packageIds(m_apps, [](PackageKitResource *resource) {
                return resource->availablePackageId();
            });
            if (ids.isEmpty()) {
                // FIXME this state shouldn't exist
                qWarning() << "Installing no packages found!";
                for (auto resource : std::as_const(m_apps)) {
                    qCDebug(LIBDISCOVER_BACKEND_PACKAGEKIT_LOG) << "app" << resource << resource->state();
                }

                setStatus(Transaction::DoneWithErrorStatus);
                return;
            }
            m_trans = PackageKit::Daemon::installPackages(ids, flags);
            break;

so...I suspect that's the issue here. We wind up telling PackageKit explicitly to install the older version, and it does. I'll see if I can manage to implement a version sort, and if so, whether that fixes the problem, though there might wind up being a better solution than that?

OK, I sent a sort of sketch of a fix. It's not very good C code and probably needs cleaning up, but in my testing at least it does *work*. If anyone else wants to try it out, the scratch build is https://koji.fedoraproject.org/koji/taskinfo?taskID=151473679 - update plasma-discover to that build, then reboot (just to make sure you're getting the updated code) and retry your reproducer.

I was looking at it too, but I don't have an environment to test atm, just a hobbyist. 
I found https://github.com/PackageKit/PackageKit/blob/164d6dfdc0ae1b6f779a784567fdb15cc03dec5c/backends/dnf5/dnf5-backend-utils.cpp#L436
dnf5_sort_and_emit(PkBackendJob *job, std::vector<libdnf5::rpm::Package> &pkgs)
{
	std::sort(pkgs.begin(), pkgs.end(), [](const libdnf5::rpm::Package &a, const libdnf5::rpm::Package &b) {
		bool a_installed = (a.get_install_time() > 0);
		bool b_installed = (b.get_install_time() > 0);
		if (a_installed != b_installed)
			return a_installed;
		if (a.get_name() != b.get_name())
			return a.get_name() < b.get_name();
		if (a.get_arch() != b.get_arch())
			return a.get_arch() < b.get_arch();
		return a.get_evr() < b.get_evr();
	});

	std::set<std::string> seen_nevras;
...
}

switching that to return a.get_evr() > b.get_evr(); might fix the sorted results?

I just don't really like the idea of assuming the results will always be in a specific order at all, when we don't have to.

(In reply to Adam Williamson (Fedora) from comment #14)
> OK, I sent a sort of sketch of a fix. It's not very good C code and probably
> needs cleaning up, but in my testing at least it does *work*. If anyone else
> wants to try it out, the scratch build is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=151473679 - update
> plasma-discover to that build, then reboot (just to make sure you're getting
> the updated code) and retry your reproducer.

I tried this build on F44 and it seems to fix the issue. I tried to install some packages with it and installed the correct version from the upgrades repo. I won' t be able to properly test this on a F45 VM until the evening.

Tried now the fix on a F45 VM and I confirm it works. I installed the VM, I did a full upgrade, I enabled the updates-testing repo since the upgraed disabled it, I installed the patched discover packages and lastly I installed Chromium and Krita, which both have versions available in updates-testing. In both cases Discover installed them from the updates-testing repo instead than from the fedora repo like it does without the patch.

validationform: hah, I actually just looked at the PK side myself and came up with the same change independently. I've tested that and it seems to work.

We also have an alternative approach from Alessandro Astone upstream: https://invent.kde.org/plasma/discover/-/merge_requests/1443#note_1681501

so we have three possible ways to address this now. All three have a potential risk, though, so it's not clear which to pick. I'm gonna do a bit more investigating and cogitating, then will pick one and do a build and request another RC.

FEDORA-2026-99cddc6fdf (plasma-discover-6.7.5-2.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-99cddc6fdf

FEDORA-2026-99cddc6fdf has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-99cddc6fdf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-99cddc6fdf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Will this fix be back-ported into F44?

FEDORA-2026-53b0294eb4 (plasma-discover-6.7.5-2.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-53b0294eb4

FEDORA-2026-53b0294eb4 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-53b0294eb4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-53b0294eb4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

In my testing, the fix works. The only catch is that after enabling updates-testing in Discover, I need to refresh the metadata AND restart Discover to make it see the latest versions. Outside of that, everything works as expected, it installs the latest versions from updates-testing instead of the fedora repo.

Tested plasma-discover-6.7.5-2.fc44 (FEDORA-2026-53b0294eb4) on an up-to-date Fedora 44 KDE system (Qt 6.11.2, KF6 6.31.0, Plasma 6.7.5).

Installed KRuler from Discover. kruler is available as 25.12.3-1.fc44 in fedora and 26.08.1-1.fc44 in updates. With the fix, PackageKit received:

  install-packages: kruler;26.08.1-1.fc44;x86_64;updates

The dnf transaction installed only kruler-26.08.1-1.fc44 from updates. No other packages changed and nothing was downgraded.

The fix works here, thanks. Karma +1 given on the update.

For the record this update uses my proposed fix. Upstream is more likely to go with Alessandro's long term, but we judged mine is probably the lowest-risk as a last-minute release fix.

Thanks for the fix!

I noticed that the fix is being pushed for 6.7.5, but will it also be added to 6.8.1? Otherwise, it seems like the problem would be fixed, but as soon as we update to 6.8, then the problem would return.

The upstream discussion is in https://invent.kde.org/plasma/discover/-/merge_requests/1443 . Upstream may use a different patch.

Sure, but it sounds like the patch wouldn't be added until potentially 6.8.2, leaving the bug present in the 6.8.1 that's in the repos, correct?

Not that I terribly mind if the bug returns in the 6.8.1 version (I've already found multiple workarounds), I was just asking, so that no one's caught off guard.

6.8.1 isn't in "the repos" for anything but Rawhide. My fix for this is more of a band-aid so I don't want to apply it to Rawhide yet. For Rawhide and later F45 builds I'd rather we follow what upstream decides.

FEDORA-2026-53b0294eb4 (plasma-discover-6.7.5-2.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Just updated into `plasma-discover-6.7.5-2.fc44` and can confirm that it works, installed Kate using Discover and it properly installed Kate and all of it's dependency on their latest available versions.

FEDORA-2026-99cddc6fdf (plasma-discover-6.7.5-2.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.