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:
Basically if one can do a # yum install rubygem-rails then one can do a # gem install rails-2.3.8
But with gem one can also do # gem install rails-2.3.3
Up to the rails application to specify which version (or library) to use.
So gems of different versions can coexist where rubygems rpms of different versions cannot be installed the same way and is redundant.
Assuming they can be installed in parallel then there is an issue with the package name not showing the gem version i.e rubygem-rails.noarch.
So I ended wondering why maintain rubygems rpms at all, once ruby is installed along with rubygems package then gem handles the rest.
I'm sorry if this discussion has been brought earlier but it doesn't make sense for me.
Thanks for thoughts.
Gil
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.
Regards, Mamoru
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.
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 way multiple ruby-gem rpms versions would be possible. Actually can we do multiple rpms version without conflict?
Regards,
Gil
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.
Regards, Mamoru _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
(First of all, please don't use top-posting: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Proper_posti... )
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.
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.
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".
Regards, Mamoru
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_posti... )
(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
Gilles Dubreuil wrote, at 06/24/2010 10:56 AM +9:00:
On Wed, 2010-06-23 at 18:32 +0900, Mamoru Tasaka wrote:
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)
So you are just lucky and unaware of the issues. e.g. https://rails.lighthouseapp.com/projects/8994/tickets/3685-actionpack-235-ge...
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?"
See above. i.e. parallel-install of different versions is basically unsupported.
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?
compat libs usually have libraries of different sonames and in that point compat libs are "different" packages. Also creating compat packages is _strongly_ discouraged on Fedora and unless avoidable we don't allow it (simply because we want to install several versions is not a valid reason on Fedora)
Mamoru
On Thu, 2010-06-24 at 13:17 +0900, Mamoru Tasaka wrote:
Gilles Dubreuil wrote, at 06/24/2010 10:56 AM +9:00:
On Wed, 2010-06-23 at 18:32 +0900, Mamoru Tasaka wrote:
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)
So you are just lucky and unaware of the issues. e.g. https://rails.lighthouseapp.com/projects/8994/tickets/3685-actionpack-235-ge...
I'm sorry but one example doesn't make the case. This one sounds as a bug in the library as explained.
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?"
See above. i.e. parallel-install of different versions is basically unsupported.
I understand it's not supported. That's my point.
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?
compat libs usually have libraries of different sonames and in that point compat libs are "different" packages. Also creating compat packages is _strongly_ discouraged on Fedora and unless avoidable we don't allow it (simply because we want to install several versions is not a valid reason on Fedora)
Mamoru
I understand and respect the "not encouraged" to deploy several versions of a same package. Although technically it works like in the compat libs or many other packages like opensslX and many others apps for legacy dependencies.
Therefore having two version of JVM or JDK for instance should never be allowed from an RPM point of view? And we we would have to rely on using "alternatives" to create symbolic links and stub config files?
Sorry to insist but isn't up to the user/sysadmin to decide what to install on the box? And be able to simply deploy concurrent versions of libraries?
Regards,
Gil
Gilles Dubreuil wrote, at 06/24/2010 08:57 PM +9:00:
I understand and respect the "not encouraged" to deploy several versions of a same package. Although technically it works like in the compat libs or many other packages like opensslX and many others apps for legacy dependencies.
Therefore having two version of JVM or JDK for instance should never be allowed from an RPM point of view? And we we would have to rely on using "alternatives" to create symbolic links and stub config files?
Again "you can just do the thing if you try" and "it is not supported or is against Fedora's policy" is quite a different thing.
Sorry to insist but isn't up to the user/sysadmin to decide what to install on the box? And be able to simply deploy concurrent versions of libraries?
This is no longer an issue which should be talked on ruby-sig. Please bring further discussion on devel or packaging list.
Mamoru
On Thu, 2010-06-24 at 22:13 +0900, Mamoru Tasaka wrote:
Gilles Dubreuil wrote, at 06/24/2010 08:57 PM +9:00:
I understand and respect the "not encouraged" to deploy several versions of a same package. Although technically it works like in the compat libs or many other packages like opensslX and many others apps for legacy dependencies.
Therefore having two version of JVM or JDK for instance should never be allowed from an RPM point of view? And we we would have to rely on using "alternatives" to create symbolic links and stub config files?
Again "you can just do the thing if you try" and "it is not supported or is against Fedora's policy" is quite a different thing.
Sorry to insist but isn't up to the user/sysadmin to decide what to install on the box? And be able to simply deploy concurrent versions of libraries?
This is no longer an issue which should be talked on ruby-sig. Please bring further discussion on devel or packaging list.
Mamoru
No worries Thanks
Gil
Gilles Dubreuil wrote:
Sorry to insist but isn't up to the user/sysadmin to decide what to install on the box? And be able to simply deploy concurrent versions of libraries?
You are confusing "Fedora provides to you" with "Fedora does not permit you to (...)".
-- Jeroen
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
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
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
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
Gilles Dubreuil wrote:
Hello,
I've been asking myself why there bother with rubygem packages?
Because this question has been asked more then once, and is likely to be asked in the future, I've put up a page summarizing some of the issues;
https://fedoraproject.org/wiki/Ruby_SIG:Gems_and_RPM
I'd appreciate feedback and additions to this page ;-)
-- Jeroen
ruby-sig@lists.fedoraproject.org
-
Gilles Dubreuil -
Jeroen van Meeuwen -
Karanbir Singh -
Mamoru Tasaka -
Mo Morsi