Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pod update broken due to issue with Firebase/Core dependencies #8110

Closed
jakubgs opened this issue Sep 19, 2018 · 10 comments
Closed

pod update broken due to issue with Firebase/Core dependencies #8110

jakubgs opened this issue Sep 19, 2018 · 10 comments
Labels
s1:awaiting input Waiting for input from the original author

Comments

@jakubgs
Copy link

jakubgs commented Sep 19, 2018

It seems like a bug was intrduced somewhere in this repo that breaks the dependency tree for Firebase/Core. Every time I run pod update I get the same error:

...
[!] CocoaPods could not find compatible versions for pod "Firebase/Core":
  In Podfile:
    Firebase/Core

Specs satisfying the `Firebase/Core` dependency were found, but they required a higher minimum deployment target.
CocoaPods could not find compatible versions for pod "GoogleUtilities/MethodSwizzler":
  In Podfile:
    Firebase/Core was resolved to 5.8.0, which depends on
      FirebaseAnalytics (= 5.1.2) was resolved to 5.1.2, which depends on
        GoogleUtilities/MethodSwizzler (~> 5.2.0)

Specs satisfying the `GoogleUtilities/MethodSwizzler (~> 5.2.0)` dependency were found, but they required a higher minimum deployment target.

This happens on many different machines.
@orta
Copy link
Member

orta commented Sep 19, 2018

Hey there, this looks like a great example of a question that you should ask on StackOverflow - there is an active tag CocoaPods where people can help out with questions like this. We try to keep the CocoaPods issues focused only on bug reports for the tool, and for upcoming feature requests. Which this doesn't look like.

@orta orta closed this as completed Sep 19, 2018
@paulb777
Copy link
Member

We're tracking a workaround for this Firebase repo at firebase/firebase-ios-sdk#1845. It does look like the root cause is a CocoaPods issue of failing to properly consolidate subspec versions, since the workaround is to force a version that CocoaPods should determine on its own. I'll try to provide more CocoaPods specific info later.

@paulb777 paulb777 reopened this Sep 19, 2018
@jakubgs
Copy link
Author

jakubgs commented Sep 19, 2018

Thanks for the response @paulb777 , I felt stupid for a second there.

@jakubgs jakubgs mentioned this issue Sep 19, 2018
Merged
@muthukrishnanOCS
Copy link

I have the same issue. please provide the solution

@paulb777
Copy link
Member

@muthukrishnanOCS Do a pod update. Firebase worked prevented this bug from arising with the 5.8.1 release.

I still plan to investigate the CocoaPods issue, but in the meantime, it shouldn't impact Firebase usage with the latest releases.

@paulb777
Copy link
Member

If I backup the master spec checkout (git checkout ec42bc82c802211830f43a01f4243ca8357061e4) and wipe some caches, I still reproduce the issue with 1.5.3.

With CocoaPods master, the pod install succeeds with lots of duplicate UUID warnings since two versions of GoogleUtilities get installed. Versions 1.3.2 and 5.3.0 are installed instead of the correct 5.2.3.

Any suggestions about how to debug?

@Carpemeid
Copy link

I may be mistaken with this, but maybe this #6540 is related. Excuse me if it's not.

Specifically "which means different versions of the pod were actually installed. Still don't understand how that's possible, as no other pod had a dependency on it, but probably a podspec has 10.0 requirement, while my Xcode targets have 10.2."

@stale
Copy link

stale bot commented Jan 19, 2019

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

@stale stale bot added the s1:awaiting input Waiting for input from the original author label Jan 19, 2019
@amorde amorde removed the s1:awaiting input Waiting for input from the original author label Jan 23, 2019
@stale
Copy link

stale bot commented Apr 24, 2019

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

@stale stale bot added the s1:awaiting input Waiting for input from the original author label Apr 24, 2019
@stale
Copy link

stale bot commented May 1, 2019

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍

@stale stale bot closed this as completed May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
s1:awaiting input Waiting for input from the original author
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@orta @paulb777 @jakubgs @amorde @muthukrishnanOCS @Carpemeid