[packages/python] Prevent pyconfig.h conflicts on multiarch systems
glen at delfi.ee
Wed Dec 2 13:03:45 CET 2015
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"
>> #error unsupported arch
> 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
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,
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
More information about the pld-devel-en