[Rubygems-developers] Re: [ANN] dev-utils v1.0

Eivind Eklund eivind at FreeBSD.org
Mon Oct 11 08:02:14 EDT 2004

On Mon, Oct 11, 2004 at 07:39:28AM -0400, Chad Fowler wrote:
> Thanks for the long and detailed note.  As I said previously in this 
> thread, we plan to fix our rather naive install.rb, so some of your 
> pains should go away with the next rubygems release.

Might it be feasible to use the RPA install.rb as base here?  (Mauricio,
you've probably got a better idea of the differences here than
anyone...)  This might signify adding some more policy to RubyGems,
requiring an internal directory structure a la setup.rb, but I
think that would be good in general - something like that will be
necessary to be able to handle policy for native package conversions,

And having a shared codebase here should be of benefit to everyone -
less duplicated work, less "random" divergence.

> I'd love to see your gem2rpm script when you get that sorted out.
> It's interesting that you chose to actually `gem install` as part of 
> the rpm install.  This was the  way at least a couple of us were 
> leaning when we initially considered native packaging system 
> integration.  So, you can do both rpm query and gem list and see the 
> installed lib?  The only weird thing I guess would be that you could 
> then do "gem uninstall libname" and cause your rpm database to become 
> inconsistent with reality.

In most cases, two-way integration would be a benefit (at least as an
option).  The can install with RubyGems/RPA or the local package
system, and remove with RubyGems/RPA and the local package system, and
no matter what end the user remove, it will be mirrored on the other

This is doable at least for the FreeBSD packaging system, with a slight
problem in some metadata (the metadata normally point at the point in
the filesystem where the "port" for the native package that installed
this resides, and no such location exists for what's installed from
RPA/RubyGems.  Hmmm - that could possibly be created, though...)


More information about the Rubygems-developers mailing list