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