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

Mauricio Fernández batsman.geo at yahoo.com
Mon Oct 11 08:27:22 EDT 2004


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

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

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

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

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com



More information about the Rubygems-developers mailing list