'gem install' does nto install dependencies

ruby-talk
1

I have a bizarre problem with 'gem install' (and found it has
some odd behaviour) and it is very baffling: in a given context
when I run it with '--explain' it says it would install a number
of dependencies but without '--explain' it does not install
them, just downloads them and puts them in a cache.

This happens under Ubuntu 14, under Ansible, with Ruby 2.1.0
from the Brightbox repository. The command line is:

  printenv; env GEM_SPEC_CACHE=/var/lib/gems/specs gem install [--explain] -u
--no-user-install arvados-cli"

and gets run with 'sudo' as 'root'; the two cases, including the
environment:

  http://paste.ubuntu.com/13931584/ (with '--explain')
  http://paste.ubuntu.com/13931597/ (without '--explain')

The dependencies that should get installed according to
'--explain' but don't get installed without it. I have noticed
though that they get downloaded to '/var/lib/gems/2.1.0/cache/',
but not unpacked.

2

I have a bizarre problem with 'gem install' (and found it has
some odd behaviour) and it is very baffling: in a given
context when I run it with '--explain' it says it would
install a number of dependencies but without '--explain' it
does not install them, just downloads them and puts them in a
cache. This happens under Ubuntu 14, under Ansible, with Ruby
2.1.0 from the Brightbox repository. The command line is:

I figured this out, and the reason is that the same "gems" were
installed for the 'root' user under '/root/.gem/' and apparently
'gem-install --no-user-install' considers a gem installed even
when it is installed solely for the user it is run as. I suspect
(but haven't verified) that this is because it checks whether it
is installed by looking for it in the '$GEM_PATH' which includes
the user's own gem repository.

So far I have found that installing "gems" in a shared directory
has several problem, all I think because of some not-so-funny
misdecisions in the design of the 'gem' command because if 'gem
install' is run just like that:

* It installs by default to the installing user's "gem"
  directory, unless '--no-user-install' is specified, which
  runs counter to nearly all other package managers. But even
  with that there are further issues.

* It runs with the 'umask' of the the installing user, which in
  the case of 'root' may well be '0067'. A shared-user "gem"
  should be installed with wider permissions, or at least with
  the permissions specified in its spec (ahem).

* While it installs the gems under a shared directory, under
  Ubuntu that is '/var/lib/gems/', it installs the specs files
  under '~/.gem/' (a design "decision" others have noticed).

* If a "gem" to be installed is already present in the
  installing user's own directory, it is not installed in the
  shared directory.

The workarounds that I have found for this are:

* Delete '~/.gem/'.
* Set the environment variable 'GEM_SPEC_CACHE' to
  '/var/lib/gems/specs'.
* Set 'umask 0022' explicitly.
* Run 'gem install' with '--no-user-install' explicitly.

Possibly the "Delete '~/.gem/'" step can be avoided by setting
'GEM_PATH' to just '/var/lib/gems/$VERSION/'. Potentially one
could set (on UNIX-like systems, similarly on others):

  export GEM_HOME GEM_PATH GEM_SPEC_CACHE
  RUBYGEMS_DIR='/var/lib/gems'
  RUBYVERSION='2.1.0'
  GEM_HOME="$RUBYGEMS_DIR/$RUBYVERSION"
  GEM_PATH="$RUBYGEMS_DIR/$RUBYVERSION"
  GEM_SPEC_CACHE="$RUBYGEMS_DIR/specs"

and that probably would have the same effect as
'--no-user-install' without the misdecisions.

A couple of relevant issues: