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?
Greetings, Tom
On 12/07/2011 04:09 PM, 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?
I am not sure that I have understood your question, so take the rest of my answer with a bit of salt python26 is in EPEL for quite some time. I see no reason to not make use of it in your package.
manuel
On 12/07/2011 09:09 AM, 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?
Seems okay to me, as long as it has proper Requires on python26, and works properly out of the box (e.g. it doesn't assume that python == python26 at runtime).
~tom
== Fedora Project
2011/12/7 Thomas Spura tomspur@fedoraproject.org:
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?
If I see it right, in most cases the python26 packages for EL5 are not subpackages, but packages of their own (and thus need a review) mainly in order to avoid cluttering the specfile too much (imagine a combined Fedora/EPEL specfile that also supports Py3...)
- Thomas
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.
-Toshio
2011/12/7 Toshio Kuratomi a.badger@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
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...)
Greetings, Tom
On Wed, Dec 07, 2011 at 07:10:35PM +0100, Thomas Spura wrote:
2011/12/7 Toshio Kuratomi a.badger@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
2011/12/7 Toshio Kuratomi a.badger@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"...
Greetings, Tom
On Wed, 7 Dec 2011 12:35:21 -0800, TK (Toshio) wrote:
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)?
That would work. Package definitions (and also subpackage definitions) with a missing %files list in the spec file don't produce a binary build of that package.
On Thu, Dec 08, 2011 at 09:54:40AM +0100, Thomas Spura wrote:
2011/12/7 Toshio Kuratomi a.badger@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
On Wed, Dec 7, 2011 at 3:15 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 12/07/2011 04:09 PM, Thomas Spura wrote:
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?
I am not sure that I have understood your question, so take the rest of my answer with a bit of salt python26 is in EPEL for quite some time. I see no reason to not make use of it in your package.
Sorry, maybe I could have been more concrete too...
It "looks" like a problem, when a python-foo package provides a python26-foo package (what we actually do with python3 in Fedora too). I just wasn't sure if it _is_ a problem too (but didn't think so ;))
Now that nobody sees this as a no-go, I'll go ahead and build it like proposed in other mails.
For those who want to look over it, here it is: http://koji.fedoraproject.org/koji/taskinfo?taskID=3583429
Thanks for all the feedback. Tom
2011/12/14 Thomas Spura tomspur@fedoraproject.org:
For those who want to look over it, here it is: http://koji.fedoraproject.org/koji/taskinfo?taskID=3583429
Two observations:
(1) the python26-zmq package provides a bunch of so's that are python-only and thus should be filtered out:
constants.so()(64bit) context.so()(64bit) device.so()(64bit) error.so()(64bit) initthreads.so()(64bit) message.so()(64bit) monitoredqueue.so()(64bit) poll.so()(64bit) rebuffer.so()(64bit) socket.so()(64bit) stopwatch.so()(64bit) version.so()(64bit)
(2) the python26-zmq-tests package has no real requirements, neither directly nor indirectly on python26-zmq or python26, this should also be fixed.
2011/12/14 Thomas Moschny thomas.moschny@gmail.com:
2011/12/14 Thomas Spura tomspur@fedoraproject.org:
For those who want to look over it, here it is: http://koji.fedoraproject.org/koji/taskinfo?taskID=3583429
Two observations:
(1) the python26-zmq package provides a bunch of so's that are python-only and thus should be filtered out:
constants.so()(64bit) context.so()(64bit) device.so()(64bit) error.so()(64bit) initthreads.so()(64bit) message.so()(64bit) monitoredqueue.so()(64bit) poll.so()(64bit) rebuffer.so()(64bit) socket.so()(64bit) stopwatch.so()(64bit) version.so()(64bit)
I'm unsure, how to do that the el5 way, without completely disabling the internaldependency generator. [1] Python filtering is quite different than the perl example [2]
Does anyone know an example package, that does filtering on el5? e.g. python-pyblock has python only provides too, but they don't fix it at all...
[1] http://www.redhat.com/archives/rpm-list/2005-August/msg00034.html [2] http://fedoraproject.org/wiki/EPEL:Packaging#Perl_Provides_and_Requires_Filt...
(2) the python26-zmq-tests package has no real requirements, neither directly nor indirectly on python26-zmq or python26, this should also be fixed.
Just pushed a fix to the other branches, so this will be fixed, when the requres will be fixed.
Thanks! Tom
On Wed, 14 Dec 2011 12:13:12 +0100, TS (Thomas) wrote:
2011/12/14 Thomas Moschny <>:
2011/12/14 Thomas Spura <>:
For those who want to look over it, here it is: http://koji.fedoraproject.org/koji/taskinfo?taskID=3583429
Two observations:
(1) the python26-zmq package provides a bunch of so's that are python-only and thus should be filtered out:
constants.so()(64bit) context.so()(64bit) device.so()(64bit) error.so()(64bit) initthreads.so()(64bit) message.so()(64bit) monitoredqueue.so()(64bit) poll.so()(64bit) rebuffer.so()(64bit) socket.so()(64bit) stopwatch.so()(64bit) version.so()(64bit)
Well, it's a vague SHOULD and not anything like important, *if* the automatic SONAME Provides are non-versioned *and* not in the lib* namespace either. They result in superfluous repo metadata. Still some form of pollution, albeit not with a high risk of confusing the depsolver.
No [other] package ought to depend on such non-versioned SONAMEs. If it did, that could be an indication of a poorly named system library in some package and/or something really requiring these libs and possibly expecting to find them in run-time linker's search path instead of a private plugin/module/extension directory.
The much more problematic SONAME Provides are those that bear a risk of conflicting with ordinary system libraries.
packaging@lists.fedoraproject.org
-
Manuel Wolfshant -
Michael Schwendt -
Thomas Moschny -
Thomas Spura -
Tom Callaway -
Toshio Kuratomi