Jeff said:
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
latform::RUBY