RPM and GEMS conflict of interest

[Gilles Dubreuil]

On Thu, 2010-06-24 at 14:58 -0400, Mohammed Morsi wrote:
> On 06/23/2010 10:14 PM, Gilles Dubreuil wrote:
> > On Wed, 2010-06-23 at 10:22 +0100, Karanbir Singh wrote:
> >    
> >> On 23/06/2010 08:36, Gilles Dubreuil wrote:
> >>      
> >>> I'm sorry if this discussion has been brought earlier but it doesn't
> >>> make sense for me.
> >>>        
> >> RPMS and Gems target very different audiences. Gem's are a very badly
> >> thought out process to help developers get to specific code easily and
> >> quickly across different platforms. Things get even worse when you
> >> include components like 'bundler', and its back to 1990's with its
> >> static linking again.
> >>
> >> RPMS on the other hand will always give you a better, managed and
> >> reproduceable environment. And this is across many levels, eg: I dont
> >> want to have mysql-devel, gcc and its whole stack installed on a machine
> >> just because i need ruby-mysql and the gem payload is native source.
> >> Then expand that to egg's for python, pecl for php, cpan for perl etc etc.
> >>
> >> - KB
> >>      
> > Do you mean RPMs are more system management oriented and GEMS more
> > application or development oriented? Maybe, from a sysadmin or developer
> > viewpoints.
> >
> > What I see, from both practice views is the need to have multiple ruby
> > libraries directly into RPMs.
> >
> > Regards,
> > Gil
> >
> >
> >    
> Also I think part of the rpm / yum philosophy is that any given Fedora 
> release and/or repository snapshot represents a 'stable' / 'supported' 
> software stack, from the hardware drivers / kernel modules, to system / 
> developer libraries, right up to the end user applications.
> 
> Any rpm based software package that goes into that stack has to be 
> community vetted and undergo the strict requirements review process. The 
> gem package system doesn't support this, and it is way to easy for a dev 
> to push an unstable gem as a new release to rubygems.org. Yes many 
> packages get around this by depending on a particular gem version, but a 
> whole lot of them don't do this, simple specifying the dependency itself 
> (minus the version), or using the ">" or ">=" version specifiers which 
> will automatically use the latest version in the rubygems repo (which 
> may be unstable).
> 
> Its not perfect (suggestions and help improving it is always welcome), 
> but at least with the Fedora review process, alot of the potential 
> pitfalls are discovered early on, before a software package is pushed 
> into a production repository.
> 
> I agree, it can be tedious to rebundle all gems into rpms but that why 
> gem2rpm is a great project, it takes care of alot of the work for you
> 
> http://rubyforge.org/projects/gem2rpm/
> 
> Also (shameless self promotion) but I geared my Polisher project towards 
> helping w/ this process, as it sits inbetween the gemcutter webhook api 
> and gem2rpm, so that whenever a gem package is pushed to the rubygems 
> repository, polisher is instantly notified and uses the end-user's 
> configuration in conjunction with gem2rpm to automatically create a 
> corresponding rpm on release. Admittedly its still not in production, 
> has more work left to do on it, but I'm already using it to build alot 
> of gems against various Ruby versions we have bundled for Fedora, and 
> the source code is out there for anyone to use / modify.
> 
> http://github.com/movitto/polisher
> http://github.com/movitto/polisher-scripts
> 
> 
>    -Mo
> 

gem2rpm seems very handy never used though!
I guess I was trying to understand things from a high level viewpoint.

Very interesting project the "polisher".

Good continuation and thanks for your answers and time.

Regards,

Gil