On Wed, May 22, 2013 at 12:16:38PM +0200, Laurent Bigonville wrote: > Le Wed, 22 May 2013 09:11:08 +1000, > Matt Palmer <mpal...@debian.org> a écrit : > > > On Tue, May 21, 2013 at 01:35:55PM +0200, Laurent Bigonville wrote: > > > I'm not sure this is a good idea as long as both ruby 1.8 and 1.9.1 > > > are used. > > > > > > The user has the ability (using the alternatives) to switch between > > > 1.8 and 1.9.1. So that means that even if 1.9.1 is installed, the > > > user could still use 1.8 and the rubygems package might be missing. > > > > That's a possible issue. What if rubygems was a recommends? It'd > > still be pulled in normally by default, but it would at least not > > *block* removal of Ruby 1.8. Makes it rather difficult to do a sane > > dependency chain, though. > > Vagrant package is not the only package that has a hard dependency > against rubygems. I would say that the same solution should be applied > to all the other package as well.
Quite possibly. > > What does Vagrant even use rubygems for directly? It seems odd that > > a tool to manage VMs would need to install gems itself. > > Rubygems is used to manage plugins that can be loaded in vagrant. I > didn't really investigate how difficult is was to disable this feature. That sounds like you don't *need* rubygems in order to, perform the essential use of the package (manage VMs) but only to enable certain optional features. I certainly don't recall vagrant ever installing gems anywhere on my behalf (if it stuck them somewhere out of the way, I'm yet to stumble across them). In that case, making rubygems a Recommends seems entirely appropriate. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org