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
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?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code