[Distutils] Patch for new install options

[Harry Henry Gebel]

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)