On Thu, Dec 08, 2011 at 09:54:40AM +0100, Thomas Spura wrote: > 2011/12/7 Toshio Kuratomi <a.badger@xxxxxxxxx>: > > 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
Attachment:
pgphy02S8vC7h.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
