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

[Vít Ondruch]

Dne 20.12.2012 21:42, Toshio Kuratomi napsal(a):
> On Thu, Dec 20, 2012 at 04:40:17PM +0100, Vít Ondruch wrote:
>> Dne 20.12.2012 15:46, Rex Dieter napsal(a):
>>> On 12/20/2012 02:40 AM, Vít Ondruch wrote:
>>>> Dne 20.12.2012 01:43, Garrett Holmstrom napsal(a):
>>>>> On 2012-12-19 5:12, Bill Nottingham wrote:
>>>>>> Vít Ondruch (vondruch at redhat.com) said:
>>>>>>> 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?
>>>>>> 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.
>>>>> There's also the fact that the ABI for the bytecode that gets
>>>>> generated at build time is specific to each x.y series of python
>>>>> releases.
>>>> For that, you could have "Require: python-libs = 2.7" instead.
>>> What's the practical difference?
>> You follow general practices? You don't have to think if
>> {ruby,python}(abi) makes any sense for {JRuby,Jython} and what
>> version it should provide in comparison to {ruby,python}. You don't
>> force people to ask why Ruby 1.9.3 has ruby(abi) = 1.9.1. You don't
>> have to answer such question as what is {ruby,python}(abi) good for?
>>
> I don't think I follow your reasoning here:
>
> 1) If there is no python(abi) and no automatic dependency checking, then the
> packager assumes the burden of adding Requires: python-libs = VERSION in all
> of their packages.  They also assume the responsibility of figuring out what
> VERSION needs to be.  This is creating more work that should be done
> centrally.
>
> 2) If there is no python(abi) but the automatic dep checking creates the
> Provides and Requires on python-libs = VERSION, then there doesn't seem to be
> any difference in terms of the work done.  Someone who maintains the central
> dep checking still has to figure out what VERSION should be in either case.
> (And, assuming that your question about Ruby 1.9.3 having ruby(abi) = 1.9.1

Please do not judge so quickly. Ruby keeps ABI compatibility between 
Ruby 1.9.1 till Ruby 1.9.3 (check the .so name as well), hence the 
ruby(abi) = 1.9.1. If the virtual provide would not be called ruby(abi), 
it could have probably different version.

> was more than hypothetical, it sounds like there might just be a lack of
> someone performing this duty for Ruby).
>
> -Toshio

There are two types of packages for Python as well as for Ruby:

1) Packages with binary extension - these packages already have 
automatically generated dependency on python-libs/ruby-libs, as if it 
would be with C libraries for example. You don't have to explicitly 
specify anything. No python(abi) is required to mandate the correct 
Python version.

2) Plain Python/Ruby packages - here you have to somehow specify that 
the package depends on python/ruby. And here is the biggest difference 
between Python and Ruby packages. For the most of the Ruby packages, it 
does not matter with what interpreter version or implementation they run 
(yes, there are exceptions I neglect at this point). But the biggest 
difference between Ruby and Python is the Python's bytecode, which 
version specific, therefore you have to exactly specify against which 
version of python the plain Python libraries were build. You choose for 
this purpose the python(abi) virtual provide, which is probably fine, 
but I would call it python(bytecode) for example.

So my conclusion is:

For Python:
* python(abi) is unfortunate name and should be dropped.
* python(abi) should be split into virtual provides which would better 
describe their purpose

I would suggest
python(bytecode) - describes the version of Python bytecode and is 
probably the same as version of python.
python(filesystem) - this could describe the layout of Python's 
filesystem for extensions etc. I personally don't see need for this 
virtual and checking by Fedora's version should be OK IMO. I'm just 
mentioning it here, since this point appeared earlier in this discussion.
python(interpreter) - if there might be Python packages without bytecode 
(not sure if that is allowed or if it make sense), they should require 
generic python interpreter.

For Ruby:
* ruby(abi) is completely useless and should be dropped.
* there should be introduced replacement, such as ruby(interpreter), 
ruby(version) or something which would describe that package needs Ruby 
interpreter and it should conform to MRI Ruby of some version. Ideas how 
to call this virtual provide are welcome.
* ruby(filesystem) - see above the python(filesystem). I prefer checks 
by Fedora version instead, so no need for this virtual provide.


Vít




BTW Here are a relevant changelog entries, which introduces the python(abi):

* Mon Dec  6 2004 Jeff Johnson <jbj at jbj.org> 2.4-2
- add Provide: python(abi) = 2.4

* Mon Nov 24 2003 Mihai Ibanescu <misa at redhat.com> 2.3.2-6
- added a Provides: python-abi


and ruby(abi):

* Wed May 17 2006 Akira TAGOH <tagoh at redhat.com> - 1.8.4-6
- added a Provides: ruby(abi) to ruby-libs.


So Ruby packaging probably imitates Python, but hard to say what else 
was behind introduction ruby(abi).