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

[Stephan Hermann]

Dear Colleagues,


On Mon, 2008-09-01 at 12:21 -0400, Mathias Gug wrote:
> 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

Step 3 is the right thing to do, IMHO. The Sysadmin who "needs" to use
gem in the first place, is doomed anyhow. But letting the sysadmin do
his work, he/she knows very well what to do with bins/libs installed by
gem under /var/lib/gems/* . We shouldn't overrule him/her.

A manual link is just a finger click away. But it's the sysadmin who is
doing this.

Furthermore, I tried to get the old source package of the gem I was
giving as example. Sadly it's gone. Anyways, to make it again clear what
happend with this gem was this:

Gem has the possibility to give e.g. DESTDIR or other installation
locations to all included dependencies. The same as in RPM spec files or
debian/rules files. No question, this is a good way, if that works as
explained, everything is fine.

But now, the package of this particular gem wasn't a pro, and had no
clue about attaching the needed shell vars to his makefile, so he just
overruled the sysadmin or the guy who was in favour to compile this gem,
and the gem packager just forced: /usr/* as installation path. 

As there is no real trusted source of gems, mostly all packages are
non-signed, it's quite difficult for the "normal rails user" to know
what happens on his/her system, especially when building those software,
which is mostly necessary, because of different other deps e.g.
libmysqlclient, or whatever.


The problem is not distro-specific, it's upstream cruft, because they
don't have a good policy for packaging those gems. If there is something
like the debian policy, or the redhat rpm policy, I wouldn't object, but
as long there is nothing like that, most sysadmins need to be careful,
and in most cases they are, especially when they fall into a pit with
gem.


Even if I'm sounding like an old fart, regarding this, but I think the
old way of installation of gem parts in /var/lib/gems/* is much better,
and letting the sysadmin do the work is even more sane. 

The other fact is, that most gems are using newer software deps then
older distros (e.g. dapper, hardy, etch, lenny (TBR)) have. So it's
quite usual, that the sysadmin needs to break his distro anyways with
new lib dependencies. That's why we shouldn't encourage the use of gems
anyways. Much better would be, if we would have a policy in place, as we
have with php pear stuff or with perl modules. the more packaged gems we
have in our archives the better (this is not ubuntu or debian specific).
So no sysadmin has to break his system because of a faulty webapp.

regards,

\sh


-- 
Stephan '\sh' Hermann           | OSS Developer & Systemadministrator
JID: sh at linux-server.org        | http://www.sourcecode.de/
GPG ID: 0xC098EFA8              | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8