I ran into a problem with TurboGears packaging in EPEL5 where requirements in the requires.txt file in the egginfo subdirs were getting bumped upstream but without corresponding bumps in the rpm packaging, leading to yum failing to do all the upgrading I needed (filed as bug 451228 and 451231 so far).
Has anyone tackled this problem?
I had a go at trying to autogenerate the RPM metadata, I've attached my work-in-progress so far to bug 451228: https://bugzilla.redhat.com/attachment.cgi?id=309225
Thoughts? Worth finishing and turning into something in a common location for rpmbuild?
Dave
David Malcolm wrote:
I ran into a problem with TurboGears packaging in EPEL5 where requirements in the requires.txt file in the egginfo subdirs were getting bumped upstream but without corresponding bumps in the rpm packaging, leading to yum failing to do all the upgrading I needed (filed as bug 451228 and 451231 so far).
Has anyone tackled this problem?
I had a go at trying to autogenerate the RPM metadata, I've attached my work-in-progress so far to bug 451228: https://bugzilla.redhat.com/attachment.cgi?id=309225
Thoughts? Worth finishing and turning into something in a common location for rpmbuild?
Definitely worthwhile!
This should be brought up on fedora-devel or the rpm development lists so that we can get something merged into our rpm scripts.
I think it might be cleaner to generate rpm virtual provides for these. Something like perl's virtual package provides or possibly ruby's since ruby has both "normal" modules and "gem" modules:
python-sqlalchemy Provides: pythonegg(SQLAlchemy) = %{version} Provides: python(sqlalchemy) = %{version}
python-TurboGears Provides: python(turbogears) = %{version} Provides: pythonegg(TurboGears) = %{version} Requires: pythonegg(SQLAlchemy) >- 0.3.11
We'd want to run these virtual provides by the packaging committee (I'll take it there). And try to get scripts that create them to rpm devel.
-Toshio
python-devel@lists.fedoraproject.org