Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1328908 - Unable to do in-place upgrade from 5.5 to 5.6-beta2; package issue
Unable to do in-place upgrade from 5.5 to 5.6-beta2; package issue
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
5.6.0
Unspecified Unspecified
high Severity high
: Beta 2
: 5.6.0
Assigned To: Nick Carboni
Jan Krocil
upgrade
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-20 10:27 EDT by Jan Krocil
Modified: 2018-03-14 05:19 EDT (History)
10 users (show)

See Also:
Fixed In Version: 5.6.0.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-29 11:51:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1348 normal SHIPPED_LIVE CFME 5.6.0 bug fixes and enhancement update 2016-06-29 14:50:04 EDT

  None (edit)
Comment 2 Šimon Lukašík 2016-04-25 04:29:41 EDT
In the old version the default_value_for-3.0.1 and ovirt_metrics-1.1.0 are directories. In the new version these are just symlinks to ../bundle/gems/*

That means we are running to the old bug 447156.
Comment 5 Šimon Lukašík 2016-05-02 09:58:08 EDT
I cannot think of any nice solution. What we could do is to put all the gems to some other directory like jewels/. And then maintain symlinks from bundler/gems/* -> jewels/ and gems/* -> jewels/

That way we ensure that we do not change directories to symlinks or the other way around. We can do this in build section of the spec file.
Comment 7 Nick Carboni 2016-05-03 14:25:28 EDT
So this looks like it will be fixed by using a new version for git based gems. This way the new symbolic link will not collide with the old directory name.

We just need to be sure that the version we pick will not collide in the same way when we go back from git-based to a released gem after our required changes are in.
Comment 8 Nick Carboni 2016-05-03 14:42:40 EDT
https://github.com/ManageIQ/manageiq/pull/8422 updates the version of the default_value gem and should resolve this for that gem.

https://github.com/ManageIQ/manageiq/pull/8382 goes back to using a released version of the ovirt_metrics gem and should resolve this for that gem.
Comment 9 CFME Bot 2016-05-03 20:15:40 EDT
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/d05d2676f70d489582aa0507c858800e5a9c6614

commit d05d2676f70d489582aa0507c858800e5a9c6614
Author:     Joe Rafaniello <jrafanie@redhat.com>
AuthorDate: Tue May 3 13:59:33 2016 -0400
Commit:     Joe Rafaniello <jrafanie@redhat.com>
CommitDate: Tue May 3 14:35:41 2016 -0400

    Don't use git based 3.0.1, bump the version since our fork has changes.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1328908
    
    It's confusing to re-use a gem version with changes on top.  We can bump our
    version using a prerelease 3.0.2 version and not worry about colliding with
    upstream since we won't be moving to theirs until 3.0.2 is released.
    
    ```ruby
    irb(main):031:0> Gem::Requirement.new("~> 3.0.2.alpha-miq.1").satisfied_by?(Gem::Version.new("3.0.2.alpha-miq.1"))
    => true
    irb(main):032:0> Gem::Requirement.new("~> 3.0.2.alpha-miq.1").satisfied_by?(Gem::Version.new("3.0.2.alpha-miq.2"))
    => true
    irb(main):033:0> Gem::Requirement.new("~> 3.0.2.alpha-miq.1").satisfied_by?(Gem::Version.new("3.0.2"))
    => true
    ```
    
    Note, the a-z character version component is used for prereleased versions.
    You therefore cannot try to use a released gem version, 3.0.1 and add a .miq or
    something like "~> 3.0.1.miq-1` because the EXISTING 3.0.1 satisfies that
    prerelease constraint:
    
    ```ruby
    irb(main):029:0> Gem::Requirement.new("~> 3.0.1.alpha-miq.1").satisfied_by?(Gem::Version.new("3.0.1"))
    => true
    ```
    
    All that for rails 5 support from FooBarWidget default_value_for PR 57

 Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 12 luke couzens 2016-05-06 05:16:22 EDT
Tried and tested Nicks method and it works for me.
Comment 13 Nick Carboni 2016-05-06 07:51:23 EDT
(In reply to Nick Carboni from comment #8)
> https://github.com/ManageIQ/manageiq/pull/8422 updates the version of the
> default_value gem and should resolve this for that gem.
> 
> https://github.com/ManageIQ/manageiq/pull/8382 goes back to using a released
> version of the ovirt_metrics gem and should resolve this for that gem.

These PRs are both now merged. This should be fixed upstream.
Comment 14 Jan Krocil 2016-05-12 06:26:46 EDT
Verified as fixed during 5.5.4.0 to 5.6.0.5-beta2.5 in-place upgrade.
The dependency issue is no longer present.
Comment 17 errata-xmlrpc 2016-06-29 11:51:51 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1348

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