On 12/20/2012 05:40 PM, 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?
Well, general practise happens to be virtual dependencies, not package
names.
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?
The point of virtual provides is that they are not dependent of actual
package names and so are not subject to issues like distro naming
policies (and changes in them), package splits etc. This happens to be
pretty much a must for automatically generated dependencies.
For example python-libs got split out of python not that many releases
ago, but python(abi) dependencies avoided the need to modify and rebuild
every bleeping python package because of it. On top of the other already
explained rationale for python(abi) existence, that is.
As for ruby(abi), I dont know the exact rationale. I'd be mildly
surprised if it existed "just because" though.
- Panu -
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
