On Wed, Dec 07, 2011 at 07:10:35PM +0100, Thomas Spura wrote:
2011/12/7 Toshio Kuratomi <a.badger(a)gmail.com>:
> On Wed, Dec 07, 2011 at 03:09:32PM +0100, Thomas Spura wrote:
>> Hi list,
>>
>> I'm the maintainer of python-zmq and it would be nice, if I could use
>> it also on el5, but I need python26 for that.
>>
>> Would it be ok, to use it and provide a python26-zmq or is an extra
>> review request needed for that?
>> Couldn't find any guideline, that forbits it, but there doesn't seem
>> to be any naming guideline for el, isn't it?
>>
> There aren't proper guidelines for this but there is this page:
>
>
https://fedoraproject.org/wiki/Python26#Packaging_Guidelines_for_EPEL5
>
> Here's the caveats: dmalcolm is in favor of combined packaging when
> possible (ie, in the non-RHEL/EPEL split case) for packager convenience.
> I'm in favor of split packages for the reasons given on that page.
>
> It sounds like you're thinking python-zmq won't exist on EPEL6, only the
> python26-zmq subpackage. With that in mind, only the bugzilla consideration
> seems to apply.
python-zmq already is in EPEL6. It's missing in EPEL5 because
python2.4 is too old and not supported:
http://lists.zeromq.org/pipermail/zeromq-dev/2010-November/007597.html
Oops, yeah, I should have written EPEL5, not EPEL6 above.
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 be very much against having a python-zmq binary package in EPEL that
requires a python other than the main python package. It causes chaos on
a number of levels:
* User: "I wonder if I can use python-zmq for my new
feature for my RHEL5 application... it's in EPEL, I guess so."
* Packager: "python-foobar Requires: python-zmq. It's in EPEL5 so I'm going
to build python-foobar there. Hmm... why does this not work?"
* Sysadmin: "Developer needs python-zmq for his new application, okay yum
install.... Why is this pulling in python26 packages? Time to report
a bug."
-Toshio