On 2.12.2015 13:38, Petr Viktorin wrote:
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.

Turns out we forgot about translation files, so -common subpackage is actually necessary.


[...]
- 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".

Fixed.

Unless the process changed, you still need them reviewed by a core
FreeIPA developer.

<https://www.redhat.com/archives/freeipa-devel/2015-December/msg00242.html>


- 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.


See above.

--
Jan Cholasta

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

Reply via email to