On Nov 8, 2007, at 10:11 , Luis Lavena wrote: > On Nov 8, 2007 12:50 PM, Luis Lavena <[EMAIL PROTECTED]> wrote: >> On Nov 8, 2007 11:02 AM, Tom Copeland <[EMAIL PROTECTED]> wrote: >>> Further investigation shows that the indexer thinks most of the >>> wxruby >>> gems are "misnamed"; more details here: >>> >>> http://rubyforge.org/tracker/index.php? >>> func=detail&aid=15417&group_id=5&atid=102 >>> >>> Still not sure exactly which side the problem is on, though... >> >> I think is related to the RubyGems version and the specific platform: >> >> Gems made with rubygems 0.8.11, and without platform (just RUBY), >> everything works. >> Gems made with rubygems 0.8.11 but platform specific (the case of >> wxRuby), fails. >> Gems made with rubygems > 0.9.2 without platform (just RUBY), works. >> Gems made with rubygems > 0.9.2 platform specific, works. >> >> It ring a bell to someone? I'm trying to pinpoint where the specific >> RubyGems version is evaluated... so far didn't find it. > > Ok, more information: > > lib/rubygems/package.rb:568 (load_gemspec) > > it uses #from_yaml at Specification to load the metadata, and at this > point the platform get evaluated (since YAML is converting it to > Gem::Specification object). > > which fires yaml_initialize (specification.rb:734) where: > > self.platform = Gem::Platform.new @platform > > and bang!, the original platform gets destroyed.
I made some changes to record the original platform (from spec) for uninstallation to work, but didn't extend that to the indexer. > mongrel-1.0.1-mswin32.gem > wxruby-1.9.0-i386-mswin32.gem > wxruby-1.9.0-powerpc-darwin8.10.0.gem trunk has all these gems being indexed now. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
