From: Charles Comstock <cc1@...>
Date: 2004-07-23T14:22:00+09:00
Subject: Re: [ANN] Ruby Installer for Windows 1.8.2-14_RC5 (from Ruby 1.8.2 preview1)

Jeff Mitchell wrote:

> 
> RubyGems supports binary gems in the sense that you can put any file
> type, including binary, into a gem.  But there is no useful support
> for binary gems; I asked in [ruby-talk:104609] and [ruby-talk:104486]
> and in private email, all without reply.  (By "binary" I mean
> precompiled gems.)
> 
> For my gems, I experimented with a mypackage-i686-linux-ruby18-1.2.3.gem
> naming scheme but decided it was too polluting to the global gem list
> since every platform must have a separate, "unrelated" gem.  The naming
> scheme mypackage-1.2.3-i686-linux-ruby18.gem is a "Malformed version
> number" error.  The precompiled gems were also about twice as large as
> a .tbz2 of the same files.
> 
> I eventually decided to stick with tarballs with .so files until
> rubygems formally supports precompiled extensions.
> 
> This could be implemented by recognizing a -linux-i686-ruby18 suffix,
> for example.  Currently, when mypackage-1.2.3-i686-linux-ruby18.gem
> exists on gems.rubyforge.org/gems/, there is a 404 Not Found error
> for "gem -i mypackage".  A first step could be to find gems matching
> the host platform suffix when the primary search fails or when the
> user requests a binary gem.

I really think it would make more sense to have all that info stored as 
metadata in the gem format and not put it in the name.  For name 
collisions on the server just make a seperate directory for each build 
type.  The information should certainly be there but I don't know if 
it's the best idea to put it all in the name.

Actually come to think of it maybe it would make more sense on the 
server end if the gem name is actually just a directory containing each 
of the gem build types.  I dunno maybe i'm just picky, but I really 
think that packages should encode more metadata in a package system and 
less in the package name.

Charles Comstock