This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
That doesn’t work on my F38 workstation, resulting in
ostree-libs-2023.3-3.fc38.x86_64.rpm 531 kB/s | 437 kB 00:00
Problem: problem with installed package ostree-2023.4-1.fc38.x86_64
- package ostree-2023.4-1.fc38.x86_64 from @System requires libostree-1.so.1(LIBOSTREE_2023.4)(64bit), but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from @System requires ostree-libs(x86-64) = 2023.4-1.fc38, but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from updates requires libostree-1.so.1(LIBOSTREE_2023.4)(64bit), but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from updates requires ostree-libs(x86-64) = 2023.4-1.fc38, but none of the providers can be installed
- package ostree-2023.1-2.fc38.x86_64 from fedora requires ostree-libs(x86-64) = 2023.1-2.fc38, but none of the providers can be installed
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.4-1.fc38.x86_64 from @System
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.1-2.fc38.x86_64 from fedora
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.4-1.fc38.x86_64 from updates
- conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
There’s a pull request (feature branch that’s suggest to merge into the project) that’s pending. Hopefully this will be merged in soon, and released as a hotfix; then distributions can pick up an official hotfix.
TL;DR: Progress is being made. It should hopefully be fixed and then deployed soon.
--user shouldn’t be suggested as a workaround here. Most users (who use flatpak with the default behaviour of system installation) won’t be able to update their existing flatpaks by adding --user.
You can of course install new flatpaks with --user but this adds complexity to using flatpak that wasn’t there before (now you have 2 different flatpak installations to manage). I think there are no remotes configured in --user either, so you’d also have to add flathub (or whatever remotes) again.
I see the update has been pushed to stable, when will it get into Kinoite? In fact the latest deployment available is from 24 June (3 days ago). Should I just be patient or is my system borked and not downloading the latest updates?
I saw that the issue did not affect flatpaks that were installed on the system and updated from an administrator account (that is sudo flatpak update). And it also did not affect people installing flatpaks to the user account and updating via user.
It “only” affected system flatpaks being updated by the user (which is the case for almost everyone using flatpaks on Fedora), due to something that broke due to assumptions on how FUSE is used in this case. This includes using GNOME Software or KDE Discover to install and update flatpaks as well as the command line when you’re updating system flatpaks from your user account.
But that would explain why some people didn’t see a problem and it got in (even despite some tests and some QA), whereas most of us saw the issue.
I have one concrete example. When I tried to install org.flathub.flatpak-external-data-checker, it wanted to install this:
ID Branch Op Remote Download
1. org.flathub.flatpak_external_data_checker.Locale stable i flathub < 1,9 MB (partial)
2. org.freedesktop.Sdk.Locale 22.08 i flathub < 339,1 MB (partial)
3. org.freedesktop.Sdk 22.08 i flathub < 513,5 MB
4. org.flathub.flatpak-external-data-checker stable i flathub < 13,2 MB
It always failed on number 3, after about 40% progress. The locale flatpaks were installed just fine. When I tried to install just org.freedesktop.Sdk//22.08 separately, it again installed its locale just fine, and then failed again on that Sdk after about 40% progress.
That’s a misunderstanding of karma. The default karma question available under all updates is Is the update generally functional? That doesn’t refer to installation. That really refers to testing general functionality (in this case, anything related to flatpak operations). The problem is that most people don’t write what they tested, they just give thumbs up. A second problem is that this is just a randomness approach - you hope that those people who first test it and supply karma would be the ones to trigger the bug and notice it. That hasn’t happened here.
One of the improvements is to add specific test cases for flatpak, and people can then perform those steps. Let’s be sincere - almost no one does that, even for packages which have these test cases. A better improvement is to create an automated test suite which is mandatory to pass - Fedora CI is then used to execute it. That would be a significant step forward. Another solution is to require the updates to be in testing for certain time (e.g. at least 3 days, at least 1 week, etc), even if they have enough positive karma. From my experience, that’s an unpopular approach for package maintainers.