On Tue, Apr 25, 2000 at 10:22:58PM -0400, Greg Ward wrote:
On 25 April 2000, Harry Henry Gebel said:
It doesn't look like I will be done with bdist_rpm tonight, here is the patch for the now install options; they are both intended to be run by RPM or other packaging systems from within a .spec file (or equivalent) (although the RPM process may have been launched by another setup.py) Some
* when you run "setup.py install --record-install", it installs as usual and writes the list of files installed to INSTALLED_FILES in the current directory
* when you run "setup.py install --package-prefix=/tmp --record-install", then it installs to (eg.) /tmp/usr/lib/python1.5/site-packages, and writes the installed filenames -- minus the "/tmp/" prefix -- to INSTALLED_FILES
It's the addition of another, somewhat artifical, installation scheme that bothers me about this. I'm also not keen on adding yet another type of "base directory" -- we already have "install_base", "prefix", "exec_prefix", and "home", and now you want to add "root" which is sometimes stuck in ahead of the "install_base". Ugh.
Now, the goal is noble: do an installation that looks exactly like what the RPM you're creating will install, except it's not actually in the live Python installation. There's no obvious way to do this with Distutils as it stands, because if you supply --prefix, you have to supply the whole thing -- "/usr/local" or "/tmp/usr" or "/tmp/usr/local" or whatever you want. What you want is a "meta-prefix", which you called the "package prefix" or "root".
It doesn't seem like an artificial scheme to me, it is a standard method used in many RPMs, in fact almost all RPMs install into a temporary tree in order to avoid the need for root access and to preserve a system's existing installed programs, the '--package-prefix' option provides a simple and direct method of doing this. And if you can fit all of the options on one screen you don't have too many :)
./setup.py -n install \ --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix'
While this works perfectly fine, my problems with it is that it is not pretty and it presupposes that someone reading the spec file has some knowledge of the internal operations of Distutils. It is even uglier as it will appear in an actual spec file (I'm not sure why the above is a dry run, so I left the -n off of this example): ./setup.py install --prefix=$RPM_BUILD_ROOT'$sys_prefix' \ --exec-prefix=$RPM_BUILD_ROOT'$sys_exec_prefix' Compare this with: ./setup.py install --package-prefix=$RPM_BUILD_ROOT Of course, if we assume that the generated spec file will never be seen by human eyes none of this matters, but spec files are looked at by many people, such as people who are making RPMs of patched distributions, people who are trying to learn how to use RPM and people who are simply curious about what is going when they build RPMs. I think in is important to present them with a simple and clear spec file. It is true that many (most) install scripts (and makefile install targets) require just these sorts of shenanigans (and worse) to use in RPM; but as the saying goes, if all those other guys jumped off the St. Georges Bridge ... Also, with this code if you ever changed the meaning of sys_prefix or sys_exec_prefix (or replaced them with something else) people with old source RPMs would no longer be able to build them on machines running a version of Distutils with the new conventions. While the meaning of these attributes may be unlikely to change, I think it is a bad idea in principle to display internals in this manner, and thereby lock yourself into certain ways of doing things. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV)