Hi, I'd like to appeal against motu-release decision to revert the libgem-ruby upload 1.3.0~RC1really1.2.0-2ubuntu2 based on the following reasons:
On Fri, Aug 29, 2008 at 11:39:52PM +0200, Stefan Potyra wrote: > > first off, this was not an easy decision. It didn't happen so far yet, that > motu-release had to decide if an upload should indeed get reverted, and hence > this decision was done only with consent among all motu-release members. The > key factor in regards to this decision was if this upload does work towards > making an improvement in regards to the intrepid-release, or if it did in > fact > result in the opposite, hence making it unfit for release. > Let me reiterate what the upload was trying to achieve. As outlined in [1]: Providing binaries shipped by gems on the default path. In hardy, the end user using a gem (let's say the rails gem) would have to do the following things: 1. sudo apt-get install rubygems 2. sudo gem install rails 3. Modify the default PATH in the environment to include /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the command line. The upload aims at removing step number 3 from the process by symlinking the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/. [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026240.html > In order to find out, if 1) was a possible way, the possible regressions of > gem handling in the change were examined compared to the previous package. > This lead to the following findings: > > Executables of gems get symlinked via the alternatives mechanism to > /usr/local/bin. > > Using the alternatives mechanism was considered inappropriate and counter- > intuitive. > > /usr/local/bin is the first entry in $PATH, so executables installed there > override any executables installed from Debian/Ubuntu packages. > > As a result, this can lead to problems in case there is a name clash between > a > binary shipped from an Ubuntu package and a binary installed from a gem. > Among > the problems of non-determinism and possible failing behaviour of Ubuntu- > packages in case such a name-clash occurs, this situation is both hard to > detect for a user/sysadmin, but also hard to fix without modifying > /usr/local/bin in the first place (which however counter-acts the idea of the > new gem handling). > According to the FHS [2]: The /usr/local hierarchy is for use by the system administrator when installing software locally. [2]: http://pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY The reason why /usr/local/bin is first on the path is that sys admin choices for the local system are more important then the system choices. When an end user uses the gem command to install a gem he wants to install something that is not available in the archive. Lucas Nussbaum stated something similar in the bug thread [3]: > That's one problem. gem installed systems would then override apt > installed systems and I'm not sure that is where we want to go. I think it is where we want to go: if an admin installs stuff manually, that's probably because the things provided by the distro don't suit his needs. So the distro stuff should be overriden by default. [3]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/25 What goes in /usr/local/ is under the responsibility of the end users. It's disappointing if end users install broken versions of things in /usr/local, but it's up to them in the end. They can download and install things in /usr/local (via CPAN, PEAR, ./configure; make; make install, or any other way) and would run into the same issue mentioned above. Trying to block people from installing 3rd party software isn't the answer. We cannot protect an admin (or user) from themselves, so we better _help_ them as much as possible. As pointed by Steve Langasek [4], there are other packages in the archive that facilitate the management of /usr/local/. Given the evidence of other /usr/local-helper tools, why should gems not be allowed to use /usr/local ? [4]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/262063/comments/4 > Especially the possible security problems arising from this approach (the > mail > from Stephan Hermann with imagemagick shipped by a gem served as an example > in > the motu-release discussion, especially since imagemagick is often called by > web applications), was considered a critical enough issue to eliminate option > 1). > Agreed. To be more precise imagemagick was installing itself in /usr/lib/ bypassing the gem infrastructure and overriding system libraries. If a gem install destroys a system, that's still the end user's fault. It'd do that if they ran the Ubuntu gem installer or the from-source gem installer. The upload doesn't make things worse nor can protect against it. > Another non-technical concern was also raised against option 1): The advice > of > developers in regards to the new gem handling was asked at [1] -- something > which motu-release unambigously encourages -- but was obviously ignored when > doing the upload in question. > I followed the whole thread [5] and replied a couple of times to outline the technical solution. Out of the answers, I've found that: * Emmet Hikory seemed in favor of using /usr/local/ [6]: policy specifically doesn't forbid the use of such tools by end-users, and we do have support for upstream behaviour for all of cpan, ezinstall, and maven. Creating correct upstream behaviour for gems as well, in a manner that doesn't damage the areas typically managed by the packaging system, is a good thing. * Stephan Hermann stated that "the whole GEM stuff is broken by design" and should not be used at all. * Scott Kitterman was against it. Comments in the bug thread [7] should also be added to this list: * Lucas suggested the idea of using /usr/local/bin in comments 13 [8], 19 [9] and 38 [10]. He also stated the as a Debian maintainer he disagreed with the proposed solution [11]. [5]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-August/004456.html [6]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-August/004474.html [7]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/ [8]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/13 [9]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/19 [10]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/38 [11]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/47 Considering that before the upload end users had to add /var/lib/gems/1.X/bin/ to their PATH in order to be able to use gems, issues raised by having gems binaries available in /usr/local/bin/ where already existing before the upload. The upload delivers the expected result by implementing an idea suggested by Lucas, one of the Debian co-maintainer. Upstream was also involved in the process: beside accepting all the patches applied to the package, they've implemented the necessary hooks so that symlinks to /usr/local/bin can be created during the gem postinstall phase. Upstream seems open for collaboration and aware of the issue. Will they provide a fix within the Intrepid timeframe ? I thought not. And last but not least I considered our end users, the Ubuntu rubyist. This issue of "where did my gem go?" was perceived as an important problem by them. I uploaded considering that it was a good technical solution: it's one step forward to improve the end user ruby experience in Intrepid. Mistakes have been made in the process: * the patch system should be reverted to the one used in Debian. * If the usage of update-alternatives seems too complicated, replacing it with a simple symlink to /usr/local/bin would also be another solution. I'm ready to fix these in order to restore the upload. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com
signature.asc
Description: Digital signature
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
