noosfero | Gem upgrade broken noosfero installation (!1624)

Rodrigo Souto gitlab at mg.gitlab.com
Thu Oct 18 11:01:00 BRT 2018


Ok, let's take a couple steps back. 

Indeed we can't run `bundle update` on Noosfero because this would change dependencies versions causing possible incompatibilities or crashes in the application. But we can upgrade the gems by defining the new version we want on the Gemfile (as you did on your request) and running `bundle install` which would update the `Gemfile.lock` as well. After this we could test to see if everything is working properly and them commit only the changes done on `Gemfile.lock` without the change you did on the `Gemfile`. This ensures that everyone is using Noosfero with the same dependencies at the same versions.

Regarding plugins as you mentioned, the plugins' `Gemfile` is added to the main  Gemfile` to ensure every plugin enabled has it's dependencies met. This process updates the `Gemfile.lock which is ok just like the `db/schema.rb` file is also updated when you enable a plugin that has some migrations and run `rake db:migrate`. The point is that we can't commit those changes neither to `Gemfile` or `Gemfile.lock` for the same reason we don't commit the changes on `db/schema.rb`: this would mess the core system with plugin's stuff. So whenever we use plugins on our systems we must use a personal changed version of the `Gemfile.lock` that is generated based on the set of plugins we have enabled.

Now regard your specific problem. If I understood correctly @maxbborges you are probably having issues with the compulsory upgrade of some gems when you install `oauth_provider` and `oauth_client` plugins. I imagine that you made this request to avoid core gems to upgrade to a newer version to met the requirements of a specific gem that is defined on those plugins since this upgrade is breaking something on Noosfero. Is that right?

If so, first of all you need to identify which tree of dependencies related to the gems required by the plugins is causing this upgrade to happen. Then you'll be able to identify if these gems can be frozen on a version that will not require these upgrades. In this case, you should freeze the version of these gems on the plugins' `Gemfile`. If the gem requirements can be met by the core gems versions then you need to ensure that all the tree of dependencies in the core `Gemfile.lock` have specific versions defined. This would stop any unnecessary upgrade. The last case is that version required by the gem of these plugins depends on an upgrade on the core gems. In this case you'd need to figure out why these upgrades are breaking (usually this happens due to incompatibilities between other gems' versions) and fix the newer versions of the gems on the core `Gemfile.lock`.

If you have any doubts feel free to contact me on Rocket Chat so we can talk more about this.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/noosfero/noosfero/merge_requests/1624#note_109950251
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20181018/aab44f43/attachment-0001.html>


More information about the Noosfero-dev mailing list