[DRE-maint] Bug#448639: rubygems and FHS compliance in Debian and Ubuntu

[Clint Byrum]

ABSTRACT

This proposal seeks to clarify the current state of the rubygems package
in Debian and Ubuntu, and provide a clear path toward full FHS compliance
and usability for users.

CURRENT STATUS

Rubygems is a tool used by ruby users to download and install ruby
modules in much the same way CPAN works for Perl, and pypi/easy_install
works for python. A developer may create a "gem" that encompasses their
software module, and publish it into the rubygems repository. Ruby users
have grown to use this as their primary source of software modules,
and as such, it is so important that it is now included with Ruby 1.9,
the latest stable release of Ruby.

One component of these modules is executable scripts. These scripts are
provided to users to perform essential functions related to whatever
module they are packaged with, or sometimes the script itself is the
entire point of the module, as is the case with the 'rails' gem, which
installs a web framework and application server. Rubygems actually
generates the files that go in to its "bindir" so that they are pointed
at the desired ruby binary.

In the upstream default install of rubygems, the default location for
these binaries and rubygems library files is /usr/bin, and /usr/lib
respectively. This places the binaries in the default shell path for most
FHS systems, so that users can have an experience something like this:

$ sudo gem install rails [... gem downloads and installs rails ... ]
$ rails my-facebook-killer-app/ [... A skeleton of a rails app is
created ...  ... I Start hacking on my-facebook-killer-app ...]

A few years ago, these two bugs were filed, and fixed, in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458987

These were fixed by having rubygems change its default path, to
/var/lib/gems/$ruby_version

This definitely address the users' issue, which was basically "I don't
want the rubygems package manager to be able to easily conflict with
the debian package manager."

However, this introduced an incompatibility with the FHS definition of
the purpose of /var[1].

"/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary files.

Some portions of /var are not shareable between different systems. For
instance, /var/log, /var/lock, and /var/run. Other portions may be shared,
notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.

/var is specified here in order to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to during
system operation (as opposed to installation and software maintenance)
must be in /var."

And further, the purpose of /var/lib

"This hierarchy holds state information pertaining to an application or
the system. State information is data that programs modify while they
run, and that pertains to one specific host. Users must never need to
modify files in /var/lib to configure a package's operation.

State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between invocations
and between different instances of the same application. State information
should generally remain valid after a reboot, should not be logging
output, and should not be spooled data."

While the terms used are certainly open to interpretation, its difficult
to argue that executable scripts and libraries constitute "state
information that programs modify while they run and that pertains to
one specific host".

This potential issue with FHS compliance means rubygems may be in
violation of Section 9.1 of the debian policy manual:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1

Whats more, users do not expect to find executable scripts in /var. The
default path on current Debian systems is as follows:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and on Ubuntu:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Adding entries to the path is a non-trivial activity that most users
won't do in a way that makes their system maintainable or flexible over
a long period of time.

PROPOSED SOLUTION

Rubygems in Debian and Ubuntu should place gems in /usr/local/lib/gems
and gem executables in /usr/local/bin.

FHS defines the purpose of /usr/local as such:

"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than
/usr unless it is being installed to replace or upgrade software in /usr."

Placing installed gems in /usr/local/lib/gems and /usr/local/bin, would
allow rubygems to maintain FHS compliance, and avoid the problem of
users accidentally overwriting dpkg installed files. This would seem a
"win win" for all issues involved.

Because the default path in the shell on most systems includes
/usr/local/bin, this would ease users' experience, and allow system
administrators to use both rubygems and dpkg/apt in the same way,
without having them conflict.

--

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html