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

Eivind Eklund eivind at FreeBSD.org
Mon Oct 11 08:59:09 EDT 2004


On Mon, Oct 11, 2004 at 08:39:30AM -0400, Chad Fowler wrote:
> 
> 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

We're talking past each other, I think.  I was thinking of the RPAfied
install.rb we use when we've got setup.rb-based projects - the one we
just need to dump in and the project is "ready" for RPA.

If this could be adapted for RubyGems (it couldn't behave exactly the
same when running in RPA context and RubyGems context, of course), this
would mean we shared one more important piece of infrastructure.  I
think it would also mean that RubyGems automatically got DESTDIR support
etc.  And it would bring things much closer to native package
conversion.

This would have the following effect on RubyGems, though:

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

... which I'd be really interested in hearing your view of, in general
:-)

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

What I was thinking of was having *all* installs done by gem/rpa to be
available in the native package list, and if the users does a native
remove, it is echoed in the gem/rpa metadata.

And yeah, doing it for every system will be a pain - but handling just
the major ones would probably give the others some incentive to handle
themselves.

Eivind.


More information about the Rubygems-developers mailing list