On Tue, Feb 23, 2010 at 02:43:14PM +0100, Lucas Nussbaum wrote: > > 4. Add support for packaged gems in Debian please :)
1st, I do not blame anyone for anything. I simply would like to point out areas where Debian is lagging behind other distributions. (using word 'lagging' without intended offence :) > While Rubygems solve some problems for some Ruby developers, as a way to > distribute the latest version of some packages, I don't think it > qualifies as the perfect way to install any ruby library on any system. > See http://pkg-ruby-extras.alioth.debian.org/rubygems.html for a text > we wrote some time ago, and still reflect our position accurately. > > You identify the main problem with Ruby packaging in Debian as being > the inability to co-install several versions of applications like rails, > because the different versions depend on different versions of some > libraries, which are incompatible with each other. > You blame our packaging system for that, and propose to package > libraries as rubygems. > > I disagree. I think that the fundamental problem is a lack of education > of developers in the ruby community, wrt API stability, for example. 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? > 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' 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. > If the Ruby community can't fix its own mess, maybe we should consider > reducing the number of Ruby things that we package. If we can't package > Rails in a satisfactory way, let's just drop the package. Maybe, then, > more people will complain about not having a rails package in Debian, > and we will be able to explain our POV. It still better than having > people complain about the state of the rubygems package. > > Note that there's also a large amount of mess around the interpreter > itself: we currently have two development branches (1.8.x and 1.9.x). > New changes are regularly introduced in 1.8, breaking things, and > there's no real transition plan between 1.8 and 1.9 AFAIK. Yes, ruby is a pain this way. I've seen posts (outside Debian) where apps need at least 1.8.3 but not 1.8.4 but 1.8.5+ works again :) And how about the 1.9.0 vs. 1.9.1! :) Cheers, Adam PS. No blame or faults. But if we try to keep with the perfect scenario, it will become more difficult to package ruby applications. And we will be unable to provide transitions (without changing library names, which is the rougher end of the stick). -- Adam Majer ad...@zombino.com -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223173623.ga2...@mira.lan.galacticasoftware.com
