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 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
