On 15.12.2015 15:53, Petr Viktorin wrote:
On 12/14/2015 08:18 AM, Jan Cholasta wrote:
On 4.12.2015 14:29, Jan Cholasta wrote:

On 3.12.2015 17:32, Petr Viktorin wrote:
This specfile patch makes python-ipalib noarch, by splitting out the
arch-dependent stuff.

I'm not sure if this should be done at all. Both py_default_encoding and
(especially) _ipap11helper are internal submodules of ipapython and I
don't think they should be packaged separately.

Technically they aren't – it's "import _ipap11helper", not "import
ipapython._ipap11helper". Their source is in the ipapython directory,
but they're built as independent modules.

This is an implementation detail rather than an architectural decision. For _ipap11helper, we haven't figured out how to properly put it inside ipapython, so it's build separately, but it actually is a part of ipapython.

If this is just about packaging arch-specific code separately from
noarch code, I'm not sure either - all other packages with both Python
and C modules I have seen (e.g. python-ldap, PyYAML) simply do not care
and put everything in a single arch-specific package. IMHO we should

This would mean putting everything into the architecture-specific
prefix. Currently the python files in python2-ipalib are installed into
the architecture-agnostic prefix, which is wrong, because you can't
install both python2-ipalib.i686 and python2-ipalib.x86_64 at the same

Putting everything into arch-specific prefix would mean that if you do
install both arches simultaneously, you'd get two identical copies of
ipalib, ipapython, and ipaplatform. So if having both installed is a
concern, I think the noarch bits should be split out.

I'm aware this means two identical copies of the modules, but the same thing works for python-ldap and PyYAML (as I pointed out above), so why shouldn't it work for us?

Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to