Home → Problems →

Wrong version for libnotify

Admin Functions

• Remove

Peter Suschlik

24 May, 2011 09:28 PM

Hi,

the link
https://rubygems.org/gems/libnotify
shows an incorrect version in title: "libnotify 0.5.1"
The correct version be "0.5.3".

There is also an issue from an user on github which is might related to the problem described above:
https://github.com/splattael/libnotify/issues/5
(I have no issues installing libnotify)

BTW, since 0.5.2 I'm pushing 3 platform-specific versions of libnotify (ruby, jruby and rubinius).
Since then libnotify's dashboard displays incorrect stats in "for this version".

Am I doing something wrong?

1. Support Staff 2 Posted by Luis Lavena on 24 May, 2011 09:38 PM

   

   Hello,

   RubyGems.org takes the latest version stable that has ruby as platform. In the case of libnotify, none of the 0.5.3 gems have a ruby platform, except for 0.5.1

   The source code of RubyGems is here:

   https://github.com/rubygems/gemcutter

   And the lines that are affecting you are the following ones:

   https://github.com/rubygems/gemcutter/blob/master/app/controllers/r...
   https://github.com/rubygems/gemcutter/blob/master/app/models/versio...

   Since your case is one of the few, perhaps you can checkout the application and provide a patch for it to take either the latest ruby or any platform present.

   Please let me know if that help you somehow.

   Admin Functions

   • Remove

2. 3 Posted by Peter Suschlik on 24 May, 2011 10:19 PM

   

   Hi Luis,

   thanks for your quick response and your hint about the ruby as platform.

   Instead of using Gem::Platform::CURRENT I'm using Gem::Platform::RUBY in gemspec now, which seem to solve the "title issue":
   https://github.com/splattael/libnotify/commit/4f7d23376669c418fe964...

   I'm still not sure how to use platform correctly and couldn't find good (and simple) examples for a multi platform gem.

   Do you have any hints for me?
   (If not, just close that issue ;))

   Again, thanks for your help!

   Admin Functions

   • Split
   • Remove

3. Support Staff 4 Posted by Luis Lavena on 24 May, 2011 10:31 PM

   

   Happy to hear that worked.

   Most of the times CURRENT should be used to indicate a native extension needs to be compiled

   I checked that libnotify depends on ffi, which makes that particular dependency useless.

   Most of the times gems should be simple ruby as you don't contain there platform or engine specific code (being Windows a platform or Java/Rubinius a Ruby engine)

   I see there is also a Java gem, what differences it from the others? is not using FFI or is using a pure-java library instead?

   What about the Rubinius one? it does contain any Rubinius specific code that is not contained in the other gems?

   If the answers to above questions is no, then there is no need to have a Java and a Rubinius version.

   I believe JRuby already includes a shim 'ffi' gem, so that could solve the ffi dependency.

   https://rubygems.org/gems/ffi

   By that means the java version of the gem is not required

   As for Rubinius, I don't remember, so I think it does which you should keep the rubinius gem without the ffi dependency on it.

   This is good candidate content for the new guides:

   http://guides.rubygems.org/

   ;-)

   Admin Functions

   • Remove

4. 5 Posted by Peter Suschlik on 24 May, 2011 11:23 PM

   

   Many answers & questions :)

   Rubinius has its own ffi and does not work with gem ffi.
   https://github.com/evanphx/rubinius/issues/546
   Therefore I have to exclude ffi dependency for Rubinius.

   I remember I had issues the ffi gem for Java which I can't reproduce right now.
   It just works, so I'll remove the Java version ;)

   Ok, that's it. You can close this issue now :D

   Again, thanks for your help!

   Admin Functions

   • Split
   • Remove

5. Peter Suschlik closed this discussion on 25 May, 2011 06:09 AM.

Comments are currently closed for this discussion. You can start a new one.