Bug 1275030 - Upgrade path for Vagrant from F22 to F23 is broken
Summary: Upgrade path for Vagrant from F22 to F23 is broken
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-25 04:28 UTC by Miroslav Suchý
Modified: 2016-11-30 09:18 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-30 09:18:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miroslav Suchý 2015-10-25 04:28:02 UTC
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

Comment 1 Vít Ondruch 2015-10-26 09:39:52 UTC
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

Comment 2 Vít Ondruch 2015-10-26 11:26:26 UTC
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 :/

Comment 3 Vít Ondruch 2015-10-26 11:45:26 UTC
Let's see if DNF guys has any tip how to solve this ...

Comment 4 Jaroslav Mracek 2015-10-26 13:23:21 UTC
We believe in comment 2 (-x should work but it has to be tested). Probably rubygem-celluloid is still required for something in F23.

Comment 5 Vít Ondruch 2015-10-26 13:32:47 UTC
"-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.

Comment 6 Adam Williamson 2015-11-02 18:44:38 UTC
I would suggest that perhaps the ruby package itself could obsolete gems that have been retired?

Comment 7 Adam Williamson 2015-11-02 19:59:05 UTC
Note, --allowerasing should also work, I think, and is mentioned in the dnf system upgrade documentation:

https://fedoraproject.org/wiki/DNF_system_upgrade

Comment 8 Vít Ondruch 2015-11-03 07:59:42 UTC
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.

Comment 9 Michael Adam 2015-11-03 17:33:19 UTC
(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.

Comment 10 Adam Williamson 2015-11-03 22:01:25 UTC
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.

Comment 11 Miroslav Suchý 2015-11-04 07:49:42 UTC
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.

Comment 12 Honza Silhan 2015-11-09 12:19:37 UTC
(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.

Comment 13 Charles Hudson 2015-11-09 23:51:54 UTC
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.

Comment 14 Charles Hudson 2015-11-10 15:52:36 UTC
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...

Comment 15 Adam Williamson 2015-11-11 16:41:15 UTC
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.

Comment 16 Fedora Admin XMLRPC Client 2016-07-08 09:38:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 17 Fedora End Of Life 2016-11-24 12:54:16 UTC
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.

Comment 18 Igor Gnatenko 2016-11-30 09:18:13 UTC
It's not DNF bug.


Note You need to log in before you can comment on or make changes to this bug.