[packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Elan Ruusamäe]

On 02.12.2015 09:48, Jacek Konieczny wrote:
> On 2015-12-01 23:19, Elan Ruusamäe wrote:
>> On 01.12.2015 19:49, jajcus wrote:
>>>      The hack is to have architecture-specific pyconfig-*.h files and
>>> a ghost
>>>      symlink updated with python-devel install. I hope this works.
>>
>> a cleaner way is to install wrapper header file which based on
>> preprocessor variables includes proper arch specific file
>> no triggers, no scriptlets, no ghosts.
>
> …and new compatibility problems with all the Python world,
>
>> and if the file is identical on both multilib packages, rpm will happily
>> install it without complaining
>>
>> so, it would be something like:
>>
>> #if X86_64
>> #include "py-x86_64.h"
>> #elseif IX86
>> #include "py-ix86.h"
>> #else
>> #error unsupported arch
>> #endif
>
> How would you convince python library to parse this file correctly? 
> Another PLD-specific Python patch, which would cause many standard 
> Python packages to fail?
>
> My solution is not pretty, but doesn't change a thing from the Python 
> perspective.

ee, what patch?

i'm speaking of installing "config.h" from static source111, and python 
original rename as config-ARCH.h when packaging.
and the preprocessor macros are generic, from compiler

and my solution doesn't also change a thing from python perspecitve, 
just config.h -> config-ARCH.h redirection is done on file cpp level, 
not symlink.
solution done at packaging time, not at package install time.

also my solution would make rpm -V work properly.

ps: such solution is commonly done in fedora where they do handle 
multilib more thoughtfully than us

-- 
glen