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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
