On 26 Aug 2010, at 14:51, Clint Byrum wrote: > 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.
I'm glad to receive this, I am planning on some implementation work by february to make all of this more friendly, but I want to get it right, for as many people, packagers, distros as possible. > 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: It relies on rbconfig.rb. As far as I know, rubys default prefix is /usr/local, so I should think the default is really /usr/local bin and /usr/local/lib. > $ 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 This conflict is hard to solve without patches to RubyGems to warn when it happens, I plan on doing this as part of the work in February, unless it is done sooner. I wouldn't say anyone is directly at fault, two debian packages could even do the same thing (or for example, provide the same named binary, maybe BSD grep and GNU grep). Marking these as conflicting is difficult, I would like ideally for RubyGems packagers to be able to hook this by writing a hook into their local operating system defaults configuration file, rather than them maintaining substantial patches or the like. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458987 This should be immediately solved by turning on --executable_format by default. I believe this is the default for the Debian RubyGems package now. > These were fixed by having rubygems change its default path, to > /var/lib/gems/$ruby_version I'm not 100% sure that was right, but you discuss this later. > 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." See above and below. > However, this introduced an incompatibility with the FHS definition of > the purpose of /var[1]. > > 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". Agreed, I don't think this choice was entirely correct. > This potential issue with FHS compliance means rubygems may be in > violation of Section 9.1 of the debian policy manual: I don't want to start an argument, but this isn't RubyGems that selected to use /var. > http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 Understood, and sympathetic. > Whats more, users do not expect to find executable scripts in /var. Agreed, we can do better. > PROPOSED SOLUTION > > Rubygems in Debian and Ubuntu should place gems in /usr/local/lib/gems > and gem executables in /usr/local/bin. Disagree, you've missed the Ruby version in the lib path, as such installing 1.9 and 1.8 alongside would lead to new bugs, unless you're proposing: /usr/local/lib/gems/<ruby-version>/gems This is similar to now, it just removes the ruby portion of the path. I would like to suggest to ruby-core that the version used here be corrected to include patch levels and local modification suffixes, to avoid issues with native gems that link the ruby binary. I think conscientious package managers would agree with this, in which case, an example of a good enough path might be: /usr/local/lib/gems/<RbConfig::CONFIG['ruby_install_name']>-<RUBY_VERSION>-<RUBY_PATCHLEVEL>-<RbConfig::CONFIG['sitearch']>/... This should ensure maintenance of ABI compatibility without overwriting during development installs and so on. > FHS defines the purpose of /usr/local as such... > > 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. Agreed. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
