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

[Chad Fowler]

On 11-Oct-04, at 8:02 AM, 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,
> 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.
>
> And having a shared codebase here should be of benefit to everyone -
> less duplicated work, less "random" divergence.

These are interesting ideas, but I think I was unclear when I was 
talking about "install.rb".  I meant the installer for the RubyGems 
library itself.  It sounds like you're talking about the actual gem 
installer that gets invoked when "gem install" is called?

It would be interesting to see if the codebase for a large part of the 
infrastructure could be shared.  I was disappointed when I learned that 
RPA wasn't going to use RubyGems as its package manager.  Of course, 
there are philosophical differences that would either need to be worked 
out or avoided.  I wonder how much of the core of these systems could 
be the same, without the philosophical issues getting in the way.  For 
example, we're going to continue to support multiple versions of 
libraries.  I don't see that changing at any point.

It's still an interesting topic of conversation, though.

>
>> 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.
>

Yes, I agree that it's beneficial and probably even doable, but it sure 
does sound like a lot of work.  This is definitely somewhere that it 
makes sense to do this only once (not many times--once for every 
potentially created ruby package manager).

> 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...)
>
>

Lots to think over on the ride to work today ;)

Chad