Bug 168751 - rhpl hardcodes the python version, making it harder to backport
rhpl hardcodes the python version, making it harder to backport
Product: Fedora
Classification: Fedora
Component: rhpl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
Reported: 2005-09-19 21:58 EDT by Toshio Kuratomi
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-02 18:05:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to let rhpl's Makefile detect the python version (377 bytes, patch)
2005-09-19 22:05 EDT, Toshio Kuratomi
no flags Details | Diff

  None (edit)
Description Toshio Kuratomi 2005-09-19 21:58:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
rhpl hardcodes the version of python that it builds with in the Makefile.inc file.  This does not appear to be because it can only use python2.4 but because python2.4 is the version that is available in the Fedora Core version for which it is released.  This makes it harder to port the library to a distribution (for instance FC3) that uses a different version of python.

Additionally, it requires that the python interpreter value be updated by the rhpl maintainer whenever the Core python package changes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. mock -r fedora-3-x86_64-core rhpl-0.173-1.src.rpm

Actual Results:  Mock failed to rebuild the rpm for FC3.

Expected Results:  Generate rpms for FC3.

Additional info:

This was talked about in a fedora-packaging thread[1] as part of why rpm needs more macros related to python.  For this problem it seemed it was more useful to fix it in the tarball than in the spec file.  Attaching a patch to fix it in the Makefile.inc.

[1] https://www.redhat.com/archives/fedora-packaging/2005-September/thread.html
Comment 1 Toshio Kuratomi 2005-09-19 22:05:21 EDT
Created attachment 119008 [details]
Patch to let rhpl's Makefile detect the python version

This is a simple patch to Makefile.inc.  It runs the same python version
detection code as rpm's pythondeps.sh script to determine which version of
python we're building with so the package will be built with the correct
includes and installed to the correct directory.

Notes:	This works as long as the build system has the version of python
installed in the path that the package is to be compiled to.  This is true for
the Extras build system but I don't know if it's the case for the current Core
Comment 2 Jeremy Katz 2005-09-20 17:47:24 EDT
rhpl is about to undergo a variety of changes (to make it more sane for me to
maintain).  One of the changes is probably going to involve me switching it to
using distutils.

So I'm going to hold off on applying this for now.  I'll stick it on FC5Blocker,
though, so that it doesn't get lost.
Comment 3 Toshio Kuratomi 2005-09-20 18:55:37 EDT

FWIW, my first attempt to make this sane was to create a distutils setup script
but I realized that distutils doesn't have a "target" for message catalogs so
the po directory would require extra work to build.
Comment 4 Jeremy Katz 2006-02-02 18:05:10 EST
Didn't get all I wanted to done with rhpl for FC5, but went ahead and applied
this in CVS

Note You need to log in before you can comment on or make changes to this bug.