Been getting the same message as well. Talked with a fellow at Chef a few days back and he said it was nothing to worry about, just a known “annoyance”.
All the Chef employees are gathering for meetings this week, so response times to pull requests and such might be delayed but you can kick off the process by updating the the gemspec and Gemfile.lock and submitting a pull request. This will run all the tests in travis so we should know if there's any problems with the new version.
Thanks, I'll send a PR from home (can't contribute from work).
I have a local fork of Berkshelf we're using which sets the default solver to the new Ruby based solver, so I'll make the update there too. Thanks!
Edit: I just tried this out, it looks like berkshelf-api-client also has a strict version for httpclient. I might just fork httpclient internally and release a 2.6.0.2 with the merged PR.
Hmm I saw that, but it'd be nice if there was a way to globally use the Ruby solver automatically rather than updating every Berksfile. Is that something that could be done in the ~/.berkshelf/config.json or something?
I don't think it's currently written to work that way, but I think it would be easy to add this feature. Personally I don't like it because everyone on your team has to replicate this config or else they get different behaviors than you do, so I think adding a few characters in your berksfile is worth the trouble. But if you feel the tradeoffs are worth it, it's your call IMO.
I guess that's why I just changed it in the Berkshelf gem itself. Also, we have workstation cookbooks that keep everyone in sync, so a property in the ~/.berkshelf/config.json would be useful as well.
I just find the Ruby solver is so much better and actually resolves dependencies, whereas the original gecode dep solver keeps failing. There seems to be an issue that cropped up a month ago when one has a private and public supermarket in their Berksfile. The Ruby solver doesn't have any issues with it.