hardcoding API numbers

[Ken Dreyer]

Hi all,

I'm a newbie to Ruby and Gems packaging, and I was wondering about a
convention I see in the rubygem packages. I see Ruby Gems hardcode
specific version numbers, like "ruby(api) = 1.8", or "ruby(api) =
1.9.3"? In Perl modules we specify it like this:

Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

so all Perl modules will Require: whatever Perl version was in the
buildroot. This makes it easy to use the same spec throughout multiple
distros (rawhide through EL5), even when the Perl versions on each OS
happen to be different. I was wondering why Ruby's Gems would hardcode
the Ruby version number?

- Ken

[Vít Ondruch]

Dne 12.4.2012 05:07, Ken Dreyer napsal(a):
> Hi all,
>
> I'm a newbie to Ruby and Gems packaging, and I was wondering about a
> convention I see in the rubygem packages. I see Ruby Gems hardcode
> specific version numbers, like "ruby(api) = 1.8", or "ruby(api) =
> 1.9.3"? In Perl modules we specify it like this:
>
> Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
>
> so all Perl modules will Require: whatever Perl version was in the
> buildroot. This makes it easy to use the same spec throughout multiple
> distros (rawhide through EL5), even when the Perl versions on each OS
> happen to be different. I was wondering why Ruby's Gems would hardcode
> the Ruby version number?
> Ken
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Hi,

I would say that this is matter of taste.

From my point of view, I feel a bit more secure when I know that my 
package will require specific ruby abi, not some arbitrary ruby abi 
which was by coincidence available during the build. So I think it may 
prevent some errors (although unlikely errors), for the cost of a bit 
harder update when ruby(abi) is changing. On the other hand, the 
ruby(abi) change is not that often and there were needed more changes 
than just ruby(abi).

Vit