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