Hello deivid, Thanks for getting in touch with us. On Tue, Jan 07, 2020 at 05:19:00PM +0100, deivid wrote: > Hello! > > Please let me know if this is not the right place to post/discuss something > like this. This is not an issue with `rubygems-bundler` or any other debian > package. I would just like to understand better and get feedback on what's > the best way the proceed in situations like the one I will explain, and > future similar situations. > > I'm a maintainer of the upstream rubygems and bundler libraries. We're > recently getting several reports about deprecation warnings. But the > warnings are not happening in code under our control, but inside the > `rubygems-bundler` package. See > https://github.com/rubygems/rubygems/issues/3068 for example. > > The situation is: > > * Rubygems automatically loads an `operating_system.rb` file if it's > present. This file is meant for packagers to adapt rubygems for their OS. > > * In debian, this customization lives at the `rubygems-integration` package. > In particular, the file is here: https://salsa.debian.org/ruby-team/rubygems-integration/blob/19f2071a0f6e40ac04cdeae7fbcb14880aa24bf6/lib/rubygems/defaults/operating_system.rb. > > * We deprecated some constants in recent versions of rubygems. > `rubygems-integration` addressed the deprecations in https://salsa.debian.org/ruby-team/rubygems-integration/commit/0290aa5b3b2e7d1c07d91a4c8e1e971903903d57 > and shipped that as version 1.13.0 of the package. However, until the > release reaches users they will keep using old versions without the > deprecations fixed. We could ship this change as an update for stable users. > * When users run `gem update --system` to upgrade rubygems, the latest > version of rubygems (which deprecates the constants) gets installed on their > system, and they start getting all the warnings because the > `operating_system.rb` file is not updated. > > So, my question is, what would be a good way to alleviate this problem and > improve the situation? > > Some thoughts: > > * Users shouldn't upgrade rubygems through the `gem update --system` way, > they should use their package manager for that. However, I'm not sure if > debian provides such a way, since there seems to be no separate `rubygems` > package? we used to have a separate rubygems package, but when ruby started embedding rubygems we decided to remove it. Maybe we could reintroduce it; we even have a request from a member of the Debian security team for that (for a different reason): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926278 We could also use rubygems-integration itself to prevent `gem update --system`, with a switch to force it if the user really wants it. IIRC the old rubygems package carried a patch doing so (which brought us some flack from time to time, truth be told). > * We (upstream) could maybe detect that a debian package is being updated > through `gem update --system` and show a warning or something. However, I'm > not sure of a reliable way to do that? That's tricky. > * Maybe, we (upstream) could try deprecating things only on new rubies > (which have not yet been packaged), so that by the time the debian package > is created, it already comes with the deprecations addressed. That is a good strategy in general, and it would be really helpful if you handle things upstream like that in the future.
Attachment:
signature.asc
Description: PGP signature