Comment 7 for bug 228345

Revision history for this message
Neil Wilson (neil-aldur) wrote : Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency

I think it would be better if Ubuntu started packaging Ruby in the way
that people who use it actually require.

Explain to a real user why they need to do 'apt-get install gem'
rather than 'apt-get install ruby' to be able to use Ruby properly.
They look at you daft and go off and use CentOs or Gentoo instead
where you can install ruby 1.9 and gem just works.

This "if you don't like it you can lump it" attitude is not at all
helpful to those who need to use the distribution to get real things
done.

- The Ubuntu packages need to support the gem database. For example,
currently apt Mongrel does not tell gem that it is installed which
stops the mongrel cluster gem installing properly. That requires me to
use a compiler in the real world and is a clear example of the failure
of the current Debian Ruby binary packaging mechanisms. Apt must keep
the gem database up to date if it is a package that has come from Gem
so that Gem doesn't get confused and the gem dependencies work for gem
packages not in the apt database.

- We need a better way of packaging gems with apt - preferably
automatically in the majority of cases. That means getting away for
the esoteric CDBS Makefile system and embracing Rake which somebody
constructing gems can understand and include in their system. Gem is
merely a source packaging system like tar with a relatively primitive
binary generation system. Apt is so much more powerful. Yet there are
2500 gems and next to no apt packages. That demonstrates the failure
of the current packaging model.

- The notion that when a system adminstrator installs Gems they
*don't* want the binaries on the system path is silly. Packaging is
about automation and I'm sick to death of having to do manual
alterations to the system path just because of somebody's incorrect
idea of how the world is. If gems is installed then the bin needs to
go on the system path (at the end - after /usr/games) automatically.

On 24/05/2008, Lucas Nussbaum <email address hidden> wrote:

> Feel free to install ruby from sources if you don't like the way it's
> packaged in Debian/Ubuntu. So you get the same amount of support for
> ruby and third party libs you install through gems.

No, I think it is time that the packaging system changed to support
real users doing real Ruby in the real world. There are plenty of
instances where Ubuntu has altered its policy compared to Debian. It
is preferable that the two are aligned but where there is a clear
problem with the solution offered by Debian then Ubuntu has the option
of going in a different direction. That is probably where this is
going if a solution can't be worked out. At the end of the day code
talks.

Nobody in Ruby (which is mostly Rails these days) is seriously using
the apt packages currently constructed because they are not fit for
purpose. Rails is just completely wrong, Mongrel is deficient as
pointed out above, there is no ferret package. I can just about use
the database libraries until I need a gem that depends on them - then
it all goes pear shaped. Not good enough when your business depends
upon it.

> (Btw, interesting post on this topic:
> http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html )

That's the usual technique of a clique grasping at information that
appear to support their position despite the overwhelming tide of
evidence against them. That evidence is Ruby people avoiding Debian
and Ubuntu and picking other distributions because their Ruby support
is superior, or installing compilers on their servers and using gem
because it is just so much easier.

What that article is really saying is that we need pragmatic
integration between apt and gem now. And that means realising Gem is a
*source* repository that just happens to have a simple cross platform
binary creator and a dependency system. It has advantages over apt in
some cases (allowing multiple versions of Rails on a single system for
example), but it useless in other regards (no postinst scripting,
appalling native code support and a disregard for FHS).

The systems need to work together efficiently and I've got some
reasonable well formed thoughts about how that should happened and I
know that you're doing something similar because I've been reviewing
what you've said in public.

So if you're interested in thrashing out a solution we can all work
with Lucas, then I'm all ears. Drop me a note offline.

--
Neil Wilson