Hello Eric, Thanks for your feedback. On Mon, Aug 25, 2014 at 12:56:37AM +0000, Eric Wong wrote: > Antonio Terceiro <terceiro@debian.org> wrote: > > People might solve this type of issue by just using > > RVM/ruby-build/chruby and not use the Ruby intepreter provided by Debian > > at all. But then, they have to provide security upgrades for the > > interpreter (arguably one of the most sensitive layers of the stack) > > themselves, while if they were using Debian's interpreter, they would be > > notified about security upgrades for Ruby just as they are for > > everything else that is provided by Debian, and security updates are > > easier and require less effort. > > > - what do you think? is this useful? is this a terrible idea? > > > > - is there anything else that needs to be considered? > > I'm not sure this half-solution is better than solution at all. For web > apps, things like Rails and Rack are just as security-sensitive as Ruby > itself and anybody managing their own installations of those should > already be checking with upstream for updates. Then Ruby itself becomes > one more upstream out of many. YMMV, but one could argue that upgrading Ruby is way harder than upgrading Rails or Rack. > That said, I'm not sure if there is a solution to the > upstream-moves-too-fast problem and OS distributions :< That's not exactly what I am trying to solve with this. :) I'm not by any means trying to solve everyones's problems. This is something I would use myself, for example when installing a non-packaged app or installing potentially unpackaged stuff for contributing to upstream. In neither of these cases I think it's reasonable to require someone to install an interpreter from sources for that. Also, during the Ruby BoF at DebConf I had feedback from actual users who thought this was useful. So I am going ahead with it, and let's see what happens. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature