`bundle_report` may confuse local private gem with remote public gem

[mateusdeap]

Description

I came accross this in a project where I had to upgrade rails from 5.2 to 6.1 and it had a private gem called app_store.

The issue may come up if there is a gem with the same name in the public source, in this case, rubygems.

If you go to rubygems you will find an app_store gem there. Here's the github

In this specific case, if I ran bundle_report, it would say:

app_store 0.1.0 - upgrade to 0.1.2

Which has no version restriction on rails and has not been updated in 12 years. The actual gem being used was in the engines/ folder of the project, which did have a restriction on rails and had to be altered to accept rails 6.1.

Expected behavior

bundle_report should've grouped this gem with the other private gems as having no new version found for it. Maybe, ideally, be able to tell that it is a private gem and suggest it's gemspec be updated?

Steps to reproduce

I've not tested this with other gems, but I'd try:

1. Declare some local private gem in a test project using rails 5 or 6 that has the same name of some public gem in rubygems.
2. Have the local gem be incompatible with some newer version of rails, like rails 7.
3. Make sure that it's version is equal to some version of the gem in rubygems. Don't know if this is strictly required, but it would mirror the situation I found.
4. Add it to the Gemfile like so: gem 'gem_with_same_name_as_some_remote_gem', path: '/local/path'
5. Run bundle install and then run bundle_report.

[arielj]

I'm thinking that I don't know if we can detect if two gems are not the same gem. I guess we can check some metadata in the gemspec, but that doesn't mean the gem is not the same (maybe it changed maintainers for example and the authors doesn't match but they are still the same gem?).