Bug 7052

This is not broken, this is the definition of the operator:

From http://docs.rubygems.org/read/chapter/16#page74

Some other clients of your library are not so hopeful. They fully expect that new interfaces will break their software, so they want to guard against accidently using the new interfaces. They use a PessimisticVersionConstraint that explicitly excludes your version 3.0.

gem 'library', '>= 2.2.0', '< 3.0'
Doing this is cumbersome, so RubyGems provides a pessimistic operator ~> (read: approximately greater than). Using the pessimistic operator, we get:

gem 'library', '~> 2.2'

Notice that we only include 2 digits of the version. The operator will drop the final digit of a version, then increment the remaining final digit to get the upper limit version number. Therefore â~> 2.2â is equivalent to: [â>= 2.2â, â< 3.0â]. Had we said â~> 2.2.0â, it would have been equivalent to: [â>= 2.2.0â, â< 2.3.0â]. The last digit specifies the level of granularity of version control. (Remember, you can alway supply an explicit upper limit if the pessimistic operator is too limited for you).

CC: (none) => pterjan

Hi Pascal,

(In reply to comment #1)
> This is not broken, this is the definition of the operator:
> 
> From http://docs.rubygems.org/read/chapter/16#page74
> 
> Some other clients of your library are not so hopeful. They fully expect that
> new interfaces will break their software, so they want to guard against
> accidently using the new interfaces. They use a PessimisticVersionConstraint
> that explicitly excludes your version 3.0.
> 
> gem 'library', '>= 2.2.0', '< 3.0'
> Doing this is cumbersome, so RubyGems provides a pessimistic operator ~> (read:
> approximately greater than). Using the pessimistic operator, we get:
> 
> gem 'library', '~> 2.2'
> 
> Notice that we only include 2 digits of the version. The operator will drop the
> final digit of a version, then increment the remaining final digit to get the
> upper limit version number. Therefore â~> 2.2â is equivalent to: [â>= 2.2â, â<
> 3.0â]. Had we said â~> 2.2.0â, it would have been equivalent to: [â>= 2.2.0â,
> â< 2.3.0â]. The last digit specifies the level of granularity of version
> control. (Remember, you can alway supply an explicit upper limit if the
> pessimistic operator is too limited for you).

I see. In that case, we won't be able to upgrade many Ruby packages for the time being. That sucks.

Regards,

-- Shlomi Fish

RubyInline 3.10 is already one year old and ParseTree which is from the same author has been updated in May but does not support recent RubyInline

We should probably contact him to ask about it

(In reply to comment #3)
> RubyInline 3.10 is already one year old and ParseTree which is from the same
> author has been updated in May but does not support recent RubyInline
> 
> We should probably contact him to ask about it

See:

https://github.com/seattlerb/parsetree/issues/3

and:

http://blog.zenspider.com/blog/2009/04/parsetree-eol.html

Regards,

-- Shlomi Fish

A Mandriva developer looked at this bug and told me this:

that's not a bug
notice that it's a requires, not a conflicts
ie. you may have several versions of packages providing different versions of same gem

CC: (none) => luigiwalser

As ParseTree is eolâd upstream, I would suggest dropping it. I canât even remember what required it, I think it was ruby_parser, since itâs not the case anymore, that package is no longer necessary.

As far as this bug report is concerned, I would close it as invalid, for the same reason pterjan stated above.

Regards,

CC: (none) => shikamaru

ruby-ParseTree seems to have been dropped quite some time ago.  Closing as OLD.

Status: NEW => RESOLVED
Resolution: (none) => OLD