Greg Ward wrote:
On 05 September 2000, Harry Henry Gebel said:
The contents of the spec file are included in the source RPM, that is why A think that using sys.executable should be the option and not the default.
Dammit, I'm still waiting for a light to flash on so I can understand where you guys are coming from on this. Please indulge me as I think out loud...
Assertions (please tell me if I'm misunderstanding something):
this isn't really all *that* important, as the build instructions in the .spec file only apply to people building the source RPM -- IOW, the build instructions in the .spec file in no way affect the majority of people who use the RPM, ie. those who just install the "built" RPM
in fact, the only person who *must* build the source RPM is the person who creates the RPM in the first place (although anyone creating binary RPMs for other distributions or other architectures would probably start from the source RPM)
I've been thinking hard about this -- hey, my brain is slow this weekend -- and I think I understand it a little better.
Case 1 (the status quo): put "python setup.py ..." in the build/install/ clean instructions in the .spec file. This is bad when the packager, P, uses a "non-standard" python (anything other than /usr/bin/python) to create an RPM that is intended to go in the non-standard location. This is mainly a problem when P immediately creates a built RPM from his new source RPM (the usual case, in fact); if a builder, B, turns source RPM -> built RPM on a separate system, then using the first python in the path -- most likely /usr/bin/python -- might well be the right thing to do.
Case 2: put sys.executable + " setup.py ..." in the .spec file. This fixes the above problem, but is bad in the case where P accidentally uses a non-standard python to create an RPM that is supposed to go to the standard python installation (/usr). Eg. if I forget that /usr/local/bin/python is first in my path, then any source RPMs I create will refer to /usr/local/bin/python in the .spec file, and building those source RPMs will either fail (on systems that don't have /usr/local/bin/python, probably the vast majority of installed Linux boxen out there) or will generate an RPM with the "non-standard" destination of /usr/local.
In the latter case -- accidentally using the wrong python -- it would be best if the Distutil issued a warning. I don't see an easy way to detect this, especially if someone is deliberately creating an RPM to install modules to a non-standard location. (Eg. Andrew's case of having python in /www/python/bin/python: he might want to make RPMs of common modules to install on all the web developers' workstations in /www/python.)
Both situations are subtle errors on the packager's part, and neither seem to have obvious automatic solutions. The "fix" is social engineering: let the packager decide what he wants to do with options to the bdist_rpm command, and make sure the rationale for each option is carefully documented.
The question is: which failure is more obvious and happens closest to the packager, the one who made the mistake (failed to RTFM, etc.)? That one should be the default. It seems to me that creating a source RPM (spec file) that immediately fails because of an explicit /path/to/python is better than one that works, but possibly wrongly, because of implicitly using the first python on the path.
IOW, "Explicit is better than implicit", even in snippets of shell code included in a .spec file bundled in a source RPM.
Why all the fuzz ? ;-)
Keep the status quo and add an option for those who want to play with different Python versions, e.g. --set-executable=/home/lemburg/tmp/betas/python2.0
This will make everybody happy and hide the feature well enough to not cause frequent RTFM replies. Those who need it will find it and those who can't find it won't need it ;-)