Dne 20.12.2012 19:10, Panu Matilainen napsal(a):
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@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?
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.
I appreciate virtual provides (although FPC dropped rubygem(foo) virtual provides from Ruby packaging guidelines :/ ). The thing is that no virtual provide can save you in case you discover, that its name does no more describe it purpose. So for Ruby MRI and JRuby, we should probably introduce ruby(interpreter) or ruby(compatibility) virtual provide instead of ruby(abi).
Vít
- Panu -
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging