Re: rails: New upstream release 2.3.5
On 23/02/10 at 11:36 -0600, Adam Majer wrote:
> On Tue, Feb 23, 2010 at 02:43:14PM +0100, Lucas Nussbaum wrote:
> This may be correct, but if you look at C/C++ ABI and API, they are not
> stable either. Yet, it is possible to install multiple versions of a
> given library. C/C++ linker address this problem. In Ruby, that linker
> is currently gems at runtime.
>
> How do you propose we support multiple versions, like C/C++ does?
Since the language doesn't provide the co-installation of several
versions of the same library with the same name, it is the
responsibility of the developers to try to keep a stable API as much as
possible, and then, if they really fail to do that, suffix the name of
the lib with a number, for example.
Most other scripting languages (perl and python) manage to do that
properly, and don't seem to suffer from it too much.
Instead, the Ruby community advocates changing APIs as soon as the
current API is deemed suboptimal, leading to very frequent incompatible
API changes.
Note that standard shared libraries in Linux provide co-installation of
different versions of the same lib, but also loading in the same
application of different versions of the same lib (through the use of
symbol versioning). Ruby doesn't provide that, so the policy of
advocating API changes looks like a time bomb: it's easy to have an
application A require libraries B and B', with B and B' requiring a
different version of the same library C.
> > Packaging libraries as rubygems is not a valid solution, as we would end
> > up packaging several versions of the same library for different
> > applications, creating a hell for stable releases support, for example.
>
> This is correct, but adding ruby gems support does not require us to
> package all their versions. To me the most important advantages of
> being able to package gems are,
>
> 1. ability to interoperate with 3rd party gem software, and
> 2. allows for versioned dependencies, similar to sonames in C/C++
>
> Now, the interop with 3rd party gem software is kind of important for
> users. Consider,
>
> 1. install some debian packages, let's call them active_record
> 2. you write some app that depends on active_record and some 3rd
> party gem
> 3. 3rd party gem depends on active_record
>
> Now you have a scenario where the 3rd party software may bail because
> it will not find active_record. Yes, it is partly the fault of that
> 3rd party gem. The user ends up either installing the gem manually
> into their application and maintaining it themselves, or just moves to
> gems all together and uses latest versions.
>
> On the other hand, people writing rubygems stopped doing things like,
>
> require 'foo1'
> require 'foo2'
> require 'foo3'
>
> for version 1.x, 2.x and 3.x. They do,
>
> gem 'foo', '~> 1.0'
> require 'foo'
>
> gem 'foo', '~> 2.0'
> require 'foo'
>
> gem 'foo', '~> 3.0'
> require 'foo'
That's no longer true. The recommended practice is now to express
dependencies in the gem, and use require in the lib, to avoid imposing a
package manager on the user.
> As ruby software becomes more mature (ie. ages), there will be times
> when the above software may work with 'foo' 2.x branch only for quite some
> time after 3.x is released. In Debian, this means we will not be able
> to support transitions of user software as we will have iehter foo 2.x
> or foo 3.x installed.
>
>
> Finally, rubygems has become a defacto standard of distributing ruby
> software. For many developers, the .tar.gz is going away completely in
> ruby. I think if 3rd party software wants to pull in libfoo gem, it
> should first attempt to use the Debian package instead of a 3rd party
> gem.
All of the above is a description of the current state of the Ruby
development communities, but not reasons for following them and doing
something insane.
If we can't get upstream projects to do sane things themselves, I think
that the only sane thing to do on our side is to reduce the amount of
Ruby stuff we package in Debian. Since nobody seems to be happy with the
current state of the rails package, is it really worth trying to provide
one?
What is the value added by Debian if all we provide is wrappers around
"gem install"?
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: