On Tue, 2005-09-20 at 02:31 +1000, Alan Milligan wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Toshio Kuratomi wrote:
>Hmmm... Yes; rhpl's Makefiles seem to make some rather problematic
>assumptions. What other packages do you know have similarly fragile
>upstream build scripts?
You can build rhpl on different FC's with just the pythonversion:
%define pyver %(%{__python} -c 'import sys; from string import split,
join; print join(split(split(sys.version)[0], ".")[:2], ".")')
%prep
%setup -q
make PYTHON=python%{pyver}
[...]
make install DESTDIR=$RPM_BUILD_ROOT PYTHON=python%{pyver}
This isn't the "right" solution, though. I think this should be fixed
in the rhpl Makefile instead.
Jeremy, it looks like you're in charge of the build scripts for rhpl: if
I file a bug and work on a patch, what would you like it to do?
1) Patch the spec file like above
2) Do something similar in Makefile.inc to detect the correct
pythonversion to use
3) Use autoconf
Since we're not accepting python-2.4, I've not downloaded
very much of
the FC4 stack to discover exactly what's still broken. In this case, I
think I was curious to see if
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been
released as we need a proper extended url basic http authentication
syntax to allow up2date to connect to our servers. Again, these patches
were submitted almost a year ago, and we still have to maintain our own
forks :(
>>make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude}
>>LIBDIR=/lib
>Why the LIBDIR? That would seems to break things for x86_64 with no
>apparent gain.
Dunno - there was obviously something screwed with the link-edit step.
I'm a little surpised that /lib is not on the default link-library path
in the first place ...
LIBDIR isn't used for linking in this case, only as a location to
install the python files to::
Makefile.inc:PYDIR=${PYTHONLIBDIR}/rhpl
Makefile.inc:PYTHONLIBDIR = /usr/$(LIBDIR)/$(PYTHON)/site-packages