On 27.11.2015 13:46, Petr Viktorin wrote:
On 11/26/2015 11:52 AM, Jan Cholasta wrote:
1) The freeipa-common subpackage is not necessary: /etc/ipa/dnssec
should be owned by freeipa-server and everything else in /etc/ipa
currently owned by freeipa-python should be owned by freeipa-client.


If the common files are in freeipa-server or freeipa-client, then the
Python 3 packages would need to depend on those. I'd like to avoid that.

I'm not sure I follow. The files do not belong to freeipa-python, since they are used only by freeipa-server and freeipa-client. What Python 3 packages would need to depend on them?



This should be a separate patch. I have prepared one, see attachment.


2) IMO this patch does too much, it should only add the Python 3
equivalent of freeipa-python - python3-ipalib - but none of the other
packages/provides.

My reasoning for the new packages:
- python3-ipalib is the main point

Right.

- freeipa-common contains files that both the py2 and py3 versions need

See above.

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

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

Again, if you insist on doing this, do it for Python 2 as well.


3) Speaking of freeipa-python, it should be renamed to python-ipalib,
for consistency.

This should also be a separate patch, again see attachment.

I think that would just be unnecessary churn. Python 3 gives us a chance
for a fresh start, so I'm taking advantage of that, but renaming
existing packages is a pain.

Something similar was done in SSSD not long ago and according to Lukáš (CCd), it was no pain.


With the right Provides, "dnf install python-ipalib" (or python2-ipalib)
will do the right thing, and I thing that's enough.

I don't think that's good enough, since it creates an inconsistency.


4) There should be a python3-devel (and also other python3- equivalents
of python- packages) BuildRequires when Python 3 support is enabled.

I did miss that somehow. Thanks for checking.
I added python3-devel; the others are unnecessary because pylint is not
currently run on the Python3 version.

OK, I think that will do for now. Note that many of them are required for makeapi and makeaci as well.

When can we expect a Python 3 pylint patch which adds the remaining BuildRequires?

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