[Rubygems-developers] Re: [ANN] dev-utils v1.0
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?
> 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,
>> 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
>> This is doable at least for the FreeBSD packaging system, with a
>> 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  and doesn't do
> for policy compliance? I see it as a useful intermediate step but IMHO
> we should aim at high-quality policy-compliant packages built and
> 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,
>  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
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