Description of problem: Vagrant in F22 through chain of deps depend on rubygem-celluloid, however this gem has been retired and nothing obsolete it. So the upgrade to F23 is broken. How reproducible: deterministic Steps to Reproduce: 1. on F22 dnf install vagrant 2. dnf --releasever=23 --setopt=deltarpm=false --enablerepo=updates-testing distro-sync Actual results: Package: rubygem-celluloid-0.15.2-2.fc22.noarch (@fedora/22) Requires: rubygem(timers) < 1.2 Removing: rubygem-timers-1.1.0-3.fc20.noarch (@fedora/22) rubygem(timers) = 1.1.0 Updated By: rubygem-timers-4.0.1-1.fc23.noarch (fedora) rubygem(timers) = 4.0.1-1 If I try to remove rubygem-celluloid, then due dependencies I had to remove even vagrant itself. So workaround is to remove this lib and vagrant itself, do upgrade, and install vagrant again. I'm not sure if this should be fixed in vagrant.spec or some other dependencie, but I'm filing it here as it is mostly pain for Vagrant itself. Expected results: Clean upgrade path to F23
rubygem-celluloid was dependency of rubygem-listen. This dependency was removed in F23. Looking into Vagrant's dependency on Listen [1], it seems that we should be able to relax that dependency to allow smoother updates. Thoughts? [1] https://github.com/mitchellh/vagrant/commit/d5458247c7490f0eff79d3e39679a22c5d67ae81
Actually, looking at it for second time, I believe that adding "-x rubygem-timers" on your command line might help to workaround this issue. Nevertheless, I am still unclear about the right solution :/
Let's see if DNF guys has any tip how to solve this ...
We believe in comment 2 (-x should work but it has to be tested). Probably rubygem-celluloid is still required for something in F23.
"-x" works indeed, but we consider it just as a workaround. And it needs user intervention, which we would prefer to avoid. From my POV, DNF should realize, that celluloid was dependency, but it is not dependency anymore, so it should be safe to remove it in transaction, including its dependencies.
I would suggest that perhaps the ruby package itself could obsolete gems that have been retired?
Note, --allowerasing should also work, I think, and is mentioned in the dnf system upgrade documentation: https://fedoraproject.org/wiki/DNF_system_upgrade
Actually, DNF should be smart enough that rubygem-timers is leaf package after update and that rubygem-celluloid used to require rubygem-times and when rubygem-celluloid is obsoleted, rubygem-timers can be removed entirely. I can't see why there should be needed any special option to specify on command line.
(In reply to awilliam from comment #7) > Note, --allowerasing should also work, I think, and is mentioned in the dnf > system upgrade documentation: > > https://fedoraproject.org/wiki/DNF_system_upgrade --allowerasing did not work for me.
Hmm, it does seem like DNF should be able to resolve this at least with --allowerasing. I still think it would also be appropriate to obsolete the package, though.
Another solution can be to introduce new package fedora-obsoleted-packages, which will be just empty package with Obsoletes for all retired and dead packages.
(In reply to Miroslav Suchý from comment #11) > Another solution can be to introduce new package fedora-obsoleted-packages, > which will be just empty package with Obsoletes for all retired and dead > packages. That could be an option. We plan to do this approach for global package preferences using weak deps in empty metadata package. oK, we will look deeper into this issue. But even if you have a package installed as a dependency then it's still not adequate to remove it.
Please forgive me for adding my comment; it was suggested by Mr. Silhan that I use Bugzilla to report problems. I too have experienced the rubygem-celluloid obstacle which prevented me from upgrading from Fedora 22 to Fedora 23. But even after removing the package and its dependencies, I still am unable to upgrade. I am upgrading two machines from 21 to 22 and then to 23. Both machines migrated to v.22, one has also been upgraded to 23. The other has not been successful after several attempts. Concerning the problem machine (64-bit workstation with Gnome desktop): I followed the procedures in Fedora Magazine. As the article "Upgrading from Fedora 22 to Fedora 23"suggested I first tried "dnf system-upgrade download --releasever=23 --best". This command failed, noting rubygem-celluloid requires rubygem(timers)1.2 and explaining that the package was unavailable. It also suggested I add the parameter "--allowerasing" but this attempt was not successful either, as noted in comment 9. Although the majority of the packages were downloaded, some were not, evidently due to server access problems. At the end of the process an error message stated that the key to google-earth-stable-6.0.3.2197-0.x86_54.rpm was missing. In spite of these problems I tried issuing the command "dnf system-upgrade reboot" but received another error message; that the system was not ready to upgrade. I posted this information on AskFedora but was informed that the site is not a forum for these discussions. I tried an email to Mr. Silhan, who pointed me to this discussion. After reading the comments I looked at my installed packages once again. I do not have Vagrant as an installed package, but I tried uninstalling rubygem-celluloid. Along with it were removed gedit-code-assistance, gnome-code-assistance, rubygem-listen and rubygem-sass, for dependencies. I then made another attempt with "dnf system-upgrade download --releasever=23 --best". This attempt ran through to conclusion, downloading the missing packages, but ending once again with the message about the missing Google key. Once again dnf reported the system unready for upgrade. I checked installed packages once again. Yum - which until yesterday was the only package manager I knew - reports that I have Google Earth stable 7.1.1.1 not 6.0.3. I tried removing the earlier mystery version with the command "rpm -e <google etc.> --noscripts, as suggested in the FAQ, but the package could not be found. I'm not sure therefore whether the Google Earth issue is causing the problem with the upgrade, or whether there is some other contributing factor. However, at this point my options are 1) wipe the drive, make a fresh install of 23 and abandon/reinstall all other installed packages, 2) remain at Fedora 22 forever or 3) experiment. If anyone has any suggestions where to look or what to do please feel free to comment.
Update to comment 13: Not knowing any better I opted to experiment. In this order: -using YUM extended package manager 1) installed current v.22 updates -2) uninstalled google earth stable v.7 -from root searched for "googleearth" -found a googleearth folder in my home folder -found within an uninstall script, which I ran, and which failed to execute successfully. Error: "Could not find a suitable uninstall script." -searched subfolders and found a pre-un script which did execute successfully, removing mimes. -returned to root and again searched for "googleearth", this time deleting anything found. -opened terminal window and as root executed "dnf clean packages". DNF reported deleting googleearth v.6 (0 packages removed) -re-executed "dnf system-upgrade download --releasever=23 --best". This concluded successfully without errors or warnings after downloading a small number of packages; the rest were in cache already. -ran dnf system-upgrade reboot as prompted by dnf -logged in to Fedora v.22 -update began automatically, 5000+ packages upgraded. -logged into v.23 Q.E.D. HTH...
Your issue with Google Earth doesn't really relate to the issue with rubygem-celluloid at all, I don't think. They are separate problems.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
It's not DNF bug.