RPM and GEMS conflict of interest

[Mohammed Morsi]

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