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@xxxxxxxxxx) 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@xxxxxxx> 2.4-2
- add Provide: python(abi) = 2.4
* Mon Nov 24 2003 Mihai Ibanescu <misa@xxxxxxxxxx> 2.3.2-6
- added a Provides: python-abi
and ruby(abi):
* Wed May 17 2006 Akira TAGOH <tagoh@xxxxxxxxxx> - 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).
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
