RPM and GEMS conflict of interest

[Gilles Dubreuil]

On Wed, 2010-06-23 at 18:32 +0900, Mamoru Tasaka wrote: 
> (First of all, please don't use top-posting:
>   http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Proper_posting_style )
> 

(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:
> >>> Hello,
> >>>
> >>> 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
> works.
> 
> 

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,
2.0.5, 2.0.2)
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,
2.0.5, 2.0.2)
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,
2.0.5, 2.0.2)
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,
2.0.5, 2.0.2)
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,
2.0.5, 2.0.2)
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)
Bloglines4R (0.1.0)
BlueCloth (1.0.0)
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)
radiant (0.6.9)
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,
2.0.2)
rake (0.8.7, 0.8.3, 0.8.2)
...

> > Don't get me wrong I reckon rpms are very powerful and made system
> > 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
ruby-gem RPMs.

> >
> > 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
broken case. 
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
developers).

I'm not trying to get one to replace the other.
I suppose at this stage they have a different scope and therefore are
complementary.

Ultimately, I'm sure RPMs could manage that.
This isn't already the case with old legacy compat libs for instance?

Regards,
Gil