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@xxxxxxxxxx) 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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
