On 12/01/2015 02:37 PM, Jan Cholasta wrote:
> /etc/ipa/default.conf is managed by freeipa-client and thus should be owned 
> by it.
> This is a common pattern in other packages (even other FreeIPA
> sub-packages) and I don't see any reason not to follow it here as well.

OK. After your patch is applied this won't be a problem, though.

>>>> - python-ipap11helper has compiled code: with this pulled out,
>>>> python3-ipalib can be noarch
>>> This is not the goal here, but if you insist on doing it, do it for
>>> Python 2 as well.
>> It is definitely the goal of this patch to make the py3 packages as good
>> as possible. That includes making them noarch.
> It is completely unnecessary for the initial py3 support.
> I would rather maintain internal consistency than make the py3 packages
> "perfect".
>> On the other hand improving the py2 packages is not a goal of this
>> particular patch.
> Which is exactly the reason I have provided patches for py2 packages
> myself.

As far as I'm concerned, the patches look good, except for consistency
the package name should be "python2-ipalib".
Unless the process changed, you still need them reviewed by a core
FreeIPA developer.

>>>> - python3-ipatests is needed if we want to start testing the py3
>>>> packages in  CI
>>> Right.
>>>> As for new provides, Fedora's Python packaging guidelines say:
>>>> """
>>>> Using a fictional module named "example", the subpackage containing
>>>> the python2 version must provide python2-example. This is of course
>>>> always the case if the subpackage is named python2-example [...]
>>>> If the subpackage has some other name then then Provides:
>>>> python2-example
>>>> must be added explicitly (but see the %python_provide macro below).
>>>> The python3 subpackage must provide python3-example. However, as the
>>>> naming guidelines mandate that the python3 subpackage be named
>>>> python3-example, this will happen automatically.
>>>> """
>>>> so I'm now adding Provides for the top-level modules.
>>> The goal of this work is to add support for Python 3, not to comply with
>>> Fedora packaging guidelines. FreeIPA on Fedora uses its own spec file
>>> anyway.
>> The goal of this patch is to add new packages that support Python 3.
>> Yes, the Fedora spec is different, but it's heavily based on the
>> upstream one, and this is a good thing. I consider the Fedora guidelines
>> the standard in Python RPM packaging. If IPA uses different packaging
>> guidelines, can you point me to them?
> FreeIPA never fully complied to Fedora packaging guidelines AFAIK and I
> don't see any reason to start now, since nobody seemed to care so far.
> Following them in just py3 sub-packages does not improve the state of
> FreeIPA as a whole and only brings inconsistency into it, so there's no
> benefit in doing it at all.
>>> Again, if you insist on doing this, do it for Python 2 as well.

OK, when your patches are ACKed I'll send patches to both improve py2
packaging and add the new packages.

Petr Viktorin

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

Reply via email to