[Freeipa-devel] [PATCH] 0751 spec: Split out python-ipap11helper and, python-default_encoding_utf8

[Jan Cholasta]

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:
>>> Hi,
>>>
>>> On 3.12.2015 17:32, Petr Viktorin wrote:
>>>> Hello,
>>>> 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
>>> follow.
>>
>> 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
>> time.
>
> 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