Dne 21.12.2012 17:34, David Malcolm napsal(a):
On Wed, 2012-12-19 at 14:20 +0100, Vít Ondruch wrote:
Dne 19.12.2012 14:12, Bill Nottingham napsal(a):
Vít Ondruch (vondruch@redhat.com) said:
Hi,
Can somebody enlighten me, what is the purpose of ruby(abi) (replace by python(abi) if you wish) virtual provide? Especially, why Ruby packaging guidelines mandate "Requires: ruby(abi) = 1.9.1", i.e. versioned require? And why in Python packages, python(abi) is automatically generated?
It seems to me that caution is required when comparing Ruby and Python in this context. Python offers very strong ABI guarantees within a minor release, whereas iitc Ruby appears to offer ABI guarantees only within a micro release (forgive me if I'm wrong here, I'm much more familiar with Python than Ruby).
What's good for Ruby may not necessarily be good for Python, and vice versa.
In the python case, it's because that python extension modules install in a version-specific directory ($libdir/python2.7, for example.) This makes them explicitly tied to that version of python.
Well, it should be better to use "python(filesystem) = 2.7-1" or something like that IMO. It turns out that for integration of JRuby, even if we would stay with Ruby 1.9.3, we would need to change filesystem layout and ruby(abi) cannot reflect it. I feel that the above mentioned usecase is abuse of python(abi).
Using "2.7-1" would be wrong.
Python has two different binary formats with guarantees: bytecode (pyc files) and the ABI of .so files. The latter is covered by autogenerated rpm deps extracted from DSO dependencies, so e.g.:
$ rpm -qR gdb | grep python libpython2.7.so.1.0()(64bit)
but the .pyc one isn't, hence the need for the "python(abi) = " metadata.
Both of these binary formats are guaranteed to be consistent within a minor release (such as "2.7" or "3.3"). They don't change with the microrelease (2.7.3) or with the rpm version ("2.7-1").
We don't need to rebuild every python package when python itself is rebuilt; we only need to do this when updating to a new minor release (2.6 -> 2.7, or 3.2 -> 3.3).
Hope this is helpful Dave
Thank you Dave,
You confirmed my conclusion from my other email [1]. I guess you will get there later ;)
Vít
[1] http://lists.fedoraproject.org/pipermail/packaging/2012-December/008816.html