As you can see from discussions like this, if you have packages taken from RPM Fusion, upgrading to the new version of Fedora can lead to several errors. I don’t know if users will have to expect these errors in the final upgrade, but there can only be two ways: suggest users to restore the original Fedora packages that have been replaced by Fusion counterparts before upgrading, or implement an upstream algorithm that recognizes these errors and avoids them.
What do you think about it? Does anyone know if there is a workaround on this?
We’re still about a month ahead of the production release. It’s good some people are volunteering and testing out the code and finding issues. At this point, I believe the best thing to do would be for people who are testing to open bug reports on RPMFusion (or for that matter any 3rd party repository) so the issues can be investigated and resolved.
Yes, I believe that the problem comes from the fact that for some packages the distinction between free
and freeworld
has not been made, but, much more simply, 100% replacement packages have been created. Even if all these cases were reported now, the changes would only affect packages for version 40 and the current problem would remain. Many users will upgrade from GNOME Software, but I don’t know precisely if there are any differences with dnf upgrade
: for example if Software applies the--allowerasing
option by default or if it automatically ignores packages that cannot be installed due to conflicts (in my way to see would be the best solution). Whatever the answer, I believe that the problem should be addressed now because having errors during the upgrade phase would be a nuisance for users who use the computer for work and who need stability and continuity.
The issue is that 3rd party repositories are “not officially affiliated with or endorsed by the Fedora Project”. That being the case the SMEs for issues would be the maintainers of those repositories, not Fedora, that’s why you need to open bugs with the respective 3rd party repositories so they can investigate and resolve.
My personal recommendation for RPMFusion is to use the “includepkgs” option in the repo files, so you control exactly what is being installed, upgraded.
As I recall, the warnings and caveats at install time make it all too easy to enable 3rd party repositories without fully understanding that you may be digging yourself a hole that you will fall into at a later time. I would have preferred to see a much stronger warning with additional acknowledgement(s) of the risks, but that is not where we are.
While most 3rd party repository admins/packagers do try to quickly deal with issues with upgrades as soon as they are identified, they tend to be underresourced (isn’t everyone?).
Perhaps those 3rd party repositories that we allow to be enabled by a click should be expected (required?) to provide a plugin for dnf that prints a message at the top of every invokation indicating that the 3rd party repository is enabled (sort of like the redhat subscription manager indicates the status of the entitlement for CentOS systems) and that some anomalies may happen. It would not automatically fix issues, but it would provide additional hints as to where to look.
Or maybe we should remove that capability at install time. I understand the reasoning behind it, but I could see where people might view it as Fedora’s tacit endorsement. If people want to use a 3rd party repository, it’s relatively easy to do.
All of the third-party repos enabled at install time (RPM Fusion NVIDIA, RPM Fusion Steam, PyCharm copr, Google Chrome, and Flathub) should be safe. If not, then that’s a Fedora bug, because Fedora made the choice to suggest users enable those repos. (Actually, this button only enables repo metadata. The repos won’t actually be enabled unless you install software from them.)
It sounds like the problems you’re having are not caused by any of the above repos, though. In particular, RPM Fusion NVIDIA and Steam repos don’t contain any packages that replace other Fedora packages. It sounds like you’ve manually enabled the full version of RPM Fusion. Fedora will never do that. It’s supported only by the RPM Fusion developers, not by Fedora.
I totally agree with you. I only hope that a solution that is convenient for users can be found.
Third-party repositories that can be enabled during the first setup do not include generic RPM Fusion repositories, only those related to Nvidia and Steam. So I don’t think any special warnings are necessary.
As I told @gtb before, I don’t think that’s the problem. Generic RPM Fusion repositories must be installed manually. Nvidia and Steam-related repositories are not a problem.
But in this case, there is a case where the nvidia repo is the issue (there is an open rpmfusion bugzilla that is currently stalled).
Except, of course, it is the nvidia repo that is a problem for some use cases.
I was not aware of this case.
I just noticed that there is already work in progress on both sides (RPM Fusion and Fedora). So I believe that the errors related to problematic packages will be fixed before the official release.
First, why is this in Project Discussion instead of Ask Fedora? Second, the link you provide is about the OP upgrading to a pre-release version of Fedora and as the first comment he received notes, they shouldn’t be upgrading to pre-release versions if they do not know how to recover from the probable issues. Pre-release versions are for community testing, not for daily driving. If you want to live at the “bleeding edge” then make sure your toolkit can handle it. The project doesn’t need to spend resources on hand holding users through using the distro when it is a rawhide or pre-release version. Going down that road is just lunacy.
Actually, this topic should be in the water cooler IMO.
From Project Discussion to The Water Cooler
Added tech-talk and removed workstation-wg
I apologize if I have not been precise in directing the discussion to the correct category. I decided to write because I’ve been following this issue for a while and since the release of the stable version is just around the corner, I thought it would be useful to discuss it. The errors concerning the interaction with the RPM Repositories, in my opinion, would fall under the Project Discussion, since they are not just any third-party repositories, but are the ones described in the official Fedora guide. I believe that covering these aspects in this section is useful for many users. I didn’t know there was already work in progress, otherwise I wouldn’t have written.
The Fedora Discussion is a space open to everyone, and mistakes can happen; but it is precisely from mistakes that we learn.