[Fedora-packaging] purpose of ruby(abi), python(abi), etc

Vít Ondruch vondruch at redhat.com
Fri Dec 21 16:48:37 UTC 2012


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 at 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 



More information about the packaging mailing list