[Distutils] First steps with distutils...
Sat Sep 9 12:32:03 2000
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
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
* 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
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
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.
Greg Ward email@example.com
"I came, I saw, she conquered."
(The original Latin seems to have been garbled.)