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

Chad Fowler chad at chadfowler.com
Mon Oct 11 08:39:30 EDT 2004

On 11-Oct-04, at 8:27 AM, Mauricio Fernández wrote:

> On Mon, Oct 11, 2004 at 12:02:14PM +0000, Eivind Eklund wrote:
>> 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,
> Not very likely, cause rpa-base's install.rb uses rpa-base to install
> itself :)

Well, one could always:

rpa install rubygems


>> 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,
>> anyway.
> Agreed.
>> And having a shared codebase here should be of benefit to everyone -
>> less duplicated work, less "random" divergence.
> We share most of the code for the package format, at least :)

Speaking of that, should we actually switch to using a shared release 
of this code?  For example, the minitar stuff?  I hate to have separate 
copies in different projects being bug-fixed, etc.

>>> 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
>> side.
>> 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...)
> Isn't there still a problem with that sort of integration, since it
> essentially bypasses the native packaging system [1] and doesn't do 
> anything
> for policy compliance? I see it as a useful intermediate step but IMHO
> we should aim at high-quality policy-compliant packages built and 
> managed
> by the native system.

I think that's a good goal as well.  Though it's kind of a neat idea 
(but really sounds like a pain to implement for EVERY system) to be 
able to integrate rubygems (and rpa-base) more directly so that when 
libs are installed from gem -> rpm -> system, they could show up in 
"gem list".  Probably not very useful in the grand scheme of things, 

> [1] note that Chad is talking about using  gem install  as a sort of
> post-install task, not as an intermediate step to build the native
> package using DESTDIR, since he says that one would be able to
> gem uninstall foo; in other words, the corresponding RPM would be but a
> wrapper for a couple scripts to gem install/remove the corresponding
> RubyGem.
Yea.  I was actually raising the "gem uninstall" thing as an issue that 
you would run into if you did this as a post-install task.  That's how 
I interpreted what Omar says he's doing now.


More information about the Rubygems-developers mailing list