[Rubygems-developers] Re: [ANN] dev-utils v1.0
chad at chadfowler.com
Mon Oct 11 08:35:14 EDT 2004
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?
> 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.
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
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 ;)
More information about the Rubygems-developers