The first Python interpreter on my path is in /www/python/bin. I was building some RPMs today where I wanted to use the interpreter that comes with Red Hat, so I ran '/usr/bin/python1.5 setup.py bdist_rpm', and found that the RPM build script just uses 'python', so it found the first one on my path, which isn't the same as the one I wanted.
Question: should the RPM build script hard-core the full path of the interpreter binary, or does it cause problems? If specifying the full path is OK, here's a patch. (Harry, or someone else who knows RPM, should approve of this patch before considering checking it in.)
--amk
Index: bdist_rpm.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/bdist_rpm.py,v retrieving revision 1.17 diff -C2 -r1.17 bdist_rpm.py *** bdist_rpm.py 2000/08/15 13:05:35 1.17 --- bdist_rpm.py 2000/09/01 15:28:35 *************** *** 8,12 **** __revision__ = "$Id: bdist_rpm.py,v 1.17 2000/08/15 13:05:35 gward Exp $"
! import os, string import glob from types import * --- 8,12 ---- __revision__ = "$Id: bdist_rpm.py,v 1.17 2000/08/15 13:05:35 gward Exp $"
! import os, string, sys import glob from types import * *************** *** 400,406 **** # figure out default build script if self.use_rpm_opt_flags: ! def_build = 'env CFLAGS="$RPM_OPT_FLAGS" python setup.py build' else: ! def_build = 'python setup.py build' # insert contents of files
--- 400,407 ---- # figure out default build script if self.use_rpm_opt_flags: ! def_build = ('env CFLAGS="$RPM_OPT_FLAGS" %s setup.py build' ! % sys.executable ) else: ! def_build = '%s setup.py build' % sys.executable # insert contents of files
On Fri, Sep 01, 2000 at 11:33:02AM -0400, Andrew Kuchling wrote:
Question: should the RPM build script hard-core the full path of the interpreter binary, or does it cause problems? If specifying the full path is OK, here's a patch. (Harry, or someone else who knows RPM, should approve of this patch before considering checking it in.)
The problem with hard coding the path into the spec file is that it prevents the source RPM from being built on a computer that does not have python located in that place. I think a better solution would be something like:
env PATH=/usr/bin/:$PATH python setup.py bdist_rpm
Of course this only works if /usr/bin/python -> /usr/bin/python1.5 , if /usr/bin/python -> /www/python/bin/python it won't work. If that is the case, then maybe hard coding the path should be implemented as an option, to be invoked with the understanding that it could hamper source RPM portability. In practice I think most RPM-based distributions put python in /usr/bin (I use RedHat, Mandrake, and SuSE on a fairly regular basis and they all put it there), so it might only be breaking portability on a theoretical basis (at least until python > 1.5 becomes common in distributions.)
On 01 September 2000, Harry Henry Gebel said:
The problem with hard coding the path into the spec file is that it prevents the source RPM from being built on a computer that does not have python located in that place. I think a better solution would be something like:
That *might* be a feature: if I build an RPM with /usr/bin/python, and encode that path in the spec file, then I expect any target systems to have a similar Python installation, ie. /usr/bin/python had better be there. If not, we have problems.
Of course, this argument breaks down in the face of relocatable RPMs.
I would suggest two wrinkles on Andrew's patch:
* use sys.executable or "python"; sys.executable is not 100% reliable in my experience (although I've only seen it empty in one particular FastCGI script... AMK will know what I'm talking about...)
* have an option to allow "whatever python is first on the path", but make sys.executable the default
IOW, something like this:
if not self.fix_interpreter_path: python = "python" else: python = sys.executable or "python"
... and then build the command that goes in the .spec file.
Greg
On Sat, Sep 02, 2000 at 11:07:27AM -0400, Greg Ward wrote:
On 01 September 2000, Harry Henry Gebel said:
The problem with hard coding the path into the spec file is that it prevents the source RPM from being built on a computer that does not have python located in that place. I think a better solution would be something like:
That *might* be a feature: if I build an RPM with /usr/bin/python, and encode that path in the spec file, then I expect any target systems to have a similar Python installation, ie. /usr/bin/python had better be there. If not, we have problems.
This is fine for binary RPMs, but source RPMs can (and should, I believe) to be buildable on any platform using the same or a later version of RPM. In fact a great number of the packages on my system are built from source RPMs designed for other distributions; many of these I had to alter to build on Mandrake; which always annoyed me since the alterations to make them not depend on a particular distribution are usually pretty minor. The source RPMs produced by bdist_rpm now should build without modifications on any system using RPM 3 or later, no matter where python is located.
- have an option to allow "whatever python is first on the path", but make sys.executable the default
I think this is a good option, but I think source RPM compatibility should be the default, and sys.executable should be the option.
On 02 September 2000, Harry Henry Gebel said:
- have an option to allow "whatever python is first on the path", but make sys.executable the default
I think this is a good option, but I think source RPM compatibility should be the default, and sys.executable should be the option.
OK, we'll flip a coin.
*flip*
There, I won. Wasn't that easy? >grin<
But seriously, does anyone have an opinion here? As I see it, the issue is this:
* I create an RPM pair (source & binary) using /usr/bin/python * but the build instructions in the .spec file just say "python setup.py build", not "/usr/bin/python setup.py build" * you build from my source RPM on a machine where the first python in the PATH != /usr/bin/python -- eg. in Andrew's example, /www/python/bin/python, because that's how we setup our development machines at work * my modules get installed somewhere unexpected on your machine
You could flip things around and ponder what happens when I build an RPM using /foo/bar/bin/python, but I won't do that because I'm afraid it would negate my argument and obliterate my position. (Hmmm.)
The question is, under what circumstances should the .spec file refer to "/usr/bin/python" (ie. sys.executable at the time the .spec file and the RPMs are generated). My hunch is we should make this the default; Harry says this behaviour should be available, but not the default. Inertia and backwards compatibility support Harry's position. Anyone feel strongly one way or the other?
Greg
On Sat, Sep 02, 2000 at 10:35:42PM -0400, Greg Ward wrote:
says this behaviour should be available, but not the default. Inertia and backwards compatibility support Harry's position. Anyone feel strongly one way or the other?
In truth, it's not hard to work around this problem for building RPMs on a system with a non-standard extra Python installation; I simply reset my $PATH. So, while I brought the issue up in the first place, I agree that it's probably not worth fixing.
--amk
participants (4)
-
Andrew Kuchling -
Andrew Kuchling -
Greg Ward -
Harry Henry Gebel