[Distutils] prefix in bdist_rpm

[Bob Ippolito]

On Feb 23, 2006, at 9:37 AM, Pavel Roskin wrote:

> On Wed, 2006-02-22 at 23:23 -0800, Bob Ippolito wrote:
>> On Feb 22, 2006, at 10:55 PM, Pavel Roskin wrote:
>>> Including "home"?
>>
>> Sure.  Such values are infinitely valuable if a user has to convince
>> distutils to do something strange for whatever reason.  Maybe they
>> have several "home" dirs (local, workgroup, etc.) and they want to
>> choose one in particular for this installation.
>
> I see.  So, you are suggesting that some options in setup.cfg are for
> end users rather than for developers doing releases.  So, even if the
> software is a wrapper about another software that installs in $HOME by
> default, it should still default to the Python directory.

Yes.  Software that installs to $HOME by default is not very common  
anyway.  I've never personally come across a software package that  
insists it should be installed in $HOME.  If a software package  
directly supports installation at all, it should default to a prefix  
of /usr/local like (nearly, apparently) everything else does when you  
install from source.

> Apparently, distutils is good at allowing to do "something  
> strange", but
> not something I want.

It has no idea what you want, that's why it gives you control over  
the process.

>> You misunderstand how distutils works, especially its config files.
>> These configuration files have an unlimited number of valid options.
>> Whether an option is valid or not in a particular section depends on
>> which distutils commands are available.  The configuration parser
>> knows nothing about the semantics of the configuration options, and
>> the commands know nothing about the particular source of the value
>> (command line, setup.py, one of several config files, etc.).
>
> How hard would it be for bdist_rpm to report an error if "prefix",
> "exec-prefix" or "home" is found in the "install" section?   
> Probably not
> hard?
>
> But if that's not hard, could bdist_rpm simply ignore those values
> instead?  Probably even easier.  The only thing that is needed is  
> to set
> them to given values in the %install section of the specfile.

It's not hard per se, but that behavior would be wrong.  If someone  
wants to build RPMs to install to an alternate location, it should be  
allowed.

-bob