motu-release will revert libgems-ruby to the old state.

[Mathias Gug]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/motu-council/attachments/20080901/caec98c2/attachment.pgp