On Thu, Dec 08, 2011 at 09:54:40AM +0100, Thomas Spura wrote:
2011/12/7 Toshio Kuratomi <a.badger(a)gmail.com>:
> On Wed, Dec 07, 2011 at 07:10:35PM +0100, Thomas Spura wrote:
>> So
>> * python-zmq will never exist in EPEL5 (unless someone will fork
>> upstream and make it work with python2.4) or
>> * python-zmq will contain and provide python26-zmq or
>> * there will only be python26-zmq
>> The draft guidelines for EPEL5 don't cover this case...
>>
>> (I would prefer the providing solution 2 above, unless someone objects...)
>>
> Well.. when you say python-zmq will contain and provide python26-zmq, do you
> mean the python-zmq srpm will provide python26-zmq subpackage (and the main
> package won't exist... something I'm not sure works)? Or do you mean there
> will be a python-zmq package with a Provides: python26-zmq ?
I would check, if it's on epel5 and change the default __python in the
spec file and before %description would be a %package -n python26-zmq,
so "the python-zmq srpm will provide python26-zmq subpackage (and the
main package won't exist".
This works in other packages, that the main package has no %files
section (and is therefore no binary package).
I agree to your concerns about the "Provides: python26-zmq"...
Sounds good to me -- Like I say, the only drawback that I see there is the
bugzilla reporting question which is the most minor of the three problems.
-Toshio