On Wed, 2010-06-23 at 18:32 +0900, Mamoru Tasaka wrote:
(No top posting: Got it! Thanks ;-) )
Gilles Dubreuil wrote, at 06/23/2010 06:05 PM +9:00:
> On Wed, 2010-06-23 at 17:26 +0900, Mamoru Tasaka wrote:
>> Gilles Dubreuil wrote, at 06/23/2010 04:36 PM +9:00:
>>> I've been asking myself why there bother with rubygem packages?
>>> Gems have a different life cycle and are completely managed through the
>>> gem interface:
>> This works if you use gem-based packages only.
>> For example let's take alexandria http://alexandria.rubyforge.org/
>> - alexandria itself does not provide gem
>> - but alexandria depends on many rubygem modules
>> - and also depends on ruby modules which are not provided by gem
>> (mainly ruby-gnome2 related packages)
>> so with making "$ yum install alexandria" just succeed without any
>> trouble, packaging gem packages in rpm style is unavoidable.
>> Also packaging gem rpms means that
>> - we can modify the gems if needed
>> - remove files unneded on runtime, something broken, etc
>> - and also do other things
>> to use them on Fedora. In short, using rpm management has much benefit
>> for us.
> Hi Mamoru,
> I understand this functionality I didn't know about ;-)
> I also guess you're right and as long it doesn't break the gems as we
> can still install multiple gems of different versions.
Honestly saying, I also question about this statement that
"we can still install multiple gems of different versions".
For example rails 2.3.5 (in fact actionpack 2.3.5) can be compatible
with rack ~> 1.0.0. And many people already reported that with
rack 1.1.0 / 1.0.0 parallel installed, rails 2.3.5 no longer
work because rack 1.1.0 is to be loaded first.
So "we can install multiple gem of different versions" does not
mean "they work altogether correctly". If parallel-installed gems
worked, well, it is just lucky. Also I don't think that the upstream
gem module developer actually guarantee that parallel install
I don't understand why you're saying it's not working???
Maybe you had an issue on that environment?
I've been using RoR for over a year and never had problems switching
between libraries (or gems version). This is rock solid AFAIC.
I also have a RoR application deployed on a big server farm
infrastructure out there (they use Debian):
$ gem list
actionmailer (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
actionpack (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
actionwebservice (1.2.6, 1.2.3)
activerecord (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
activeresource (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
activesupport (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
acts_as_taggable (2.0.2, 1.0.4)
ajax_scaffold_generator (3.1.11, 2.2.1)
archive-tar-minitar (0.5.2, 0.5.1)
auth_generator (2.0.1, 1.5.3)
builder (2.1.2, 2.0.0)
camping (1.5.180, 1.5)
capistrano (2.5.1, 2.1.0, 1.4.1)
rack (1.1.0, 1.0.1, 1.0.0)
rails (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5,
rake (0.8.7, 0.8.3, 0.8.2)
> Don't get me wrong I reckon rpms are very powerful and made
> change management so easy.
> At same time I use Ruby more and more as well as ROR and the
> dependencies and I feel it's redundant. As I'm sure it also adds
> overhead of building the rpm specs. So where is the line?
> For instance instead of building rpm for apps which are not built as
> gems (like alexandria) into gem wouldn't it be preferable to integrate
> gem dependencies into rpms?
> Let's say a ruby app needs gems (like alexandira) so the corresponding
> rpm pack triggers "gem install" which depends initially on ruby and
> rubygems packages but would also depends on other needed rpms?
- This is the same as requesting people to install the dependencies
not available in Fedora's rpms by themselves (using gem or tarball or
so) and is against Fedora's policy.
I understand and agree with that.
It actually enforces even more the need to have multiple version of
> This way multiple ruby-gem rpms versions would be possible.
> Actually can we do multiple rpms version without conflict?
So basically I think installing multiple version is not "supportee".
GEMs provides multiple versions, that's running and if not then it's a
So it doesn't preclude the fact that this a service/function RPMs does
not provide at this stage, at least in regards of Gems.
But more specifically the fact is:
"Why different versions of programming libraries could not co-exist
straight-out of the box on a Distro?"
Fedora could make that happens (especially with it's position among
I'm not trying to get one to replace the other.
I suppose at this stage they have a different scope and therefore are
Ultimately, I'm sure RPMs could manage that.
This isn't already the case with old legacy compat libs for instance?