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.
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.
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.
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.
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/d05d2676f70d489582aa0507c858800e5a9c6614 commit d05d2676f70d489582aa0507c858800e5a9c6614 Author: Joe Rafaniello <jrafanie> AuthorDate: Tue May 3 13:59:33 2016 -0400 Commit: Joe Rafaniello <jrafanie> 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(-)
Tried and tested Nicks method and it works for me.
(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.
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.
https://github.com/ManageIQ/manageiq/pull/8473
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