Packaging: prepare building for RHEL 8+ and Fedora (iow, for Python3)

[pirat89]

The SPEC file has been simplified to make the maintaining simple for
people. As the set of changes seems biger regarding that, here
is the list of changes explicitly:

• The building for Python2 and Python3 is now exclusive.
  Python2 is supported only on RHEL 7. For all newer systems
  (Fedora including) build just with Python3.

• Additionaly the python3-leapp packages provides leapp-framework
  as expected.

• Remove auto generated python(abi) dependency on Python3 systems
  Various versions of systems (RHEL 8, RHEL 9, Fedora 33, Fedora 34)
  use different versions of Python. This means the python(abi) is
  different on each system, however leapp packages (excluding the
  deps metapackage) has to survive the upgrade of the system
  untouched. This is not possible when requirements on python(abi)
  is defined, so drop this dependency from all packages.

  • python(abi) for Python2 is kept untouched for historical reasons
    and because python 2.7 is on both - RHEL 7 and RHEL 8 systems.

• Remove autogenerated /usr/libexec/platform-python dependency on EL8
  It's analogy to the problem above. Just in this case, this dependency
  has been generated just on EL 8 systems. However the platform-python
  will not exist anymore on newer systems.

• Additionally disable auto generation of Python3 dependencies.
  The dependencies are expected to be handled via the deps package,
  however the autogenerated deps were put into the python3-leapp rpm,
  which is not what we want (it breaks our handy solution with deps
  in case of IPU).

• Set the conflifcts between python2-leapp and python3-leapp pkgs
  We build only for Python2 of Python3, so enable installation only
  one of those two packages. As well we do not want to set provides
  and bosoletes for Python2, because packages from one system cannot
  be just updated by packages from another system.

• Enable building of leapp on Fedora
  Since the leapp tool doesn't provide any specific commits, it's
  no problem to enable it's building for the Fedora - as it doesn't
  depends on leapp-repository neither. The manpage is still confusing
  but that's going to be updated in the separate PR.

---

old notes

• Comment out the python abi requirement.

  • We need to discuss this one later.
    currently, with the generated python(abi) = 3.6 it's not possible to preserve
    the rpm on RHEL 9 system. let's talk about consequences of the removal later
    • UPDATE: I have discussed that already and think it should be ok for us. However I need to find out any comment from the past where I put the result of the discussion with the python team. The problem is that python-abi on RHEL 8 is 3.6, but on RHEL 9 it's newer, which breaks the upgrade path with the leapp.

• Comment out auto generation of Python3 dependencies

  • The dependencies are expected to be handled via the deps package,
    however the autogenerated deps are put into the python3-leapp rpm,
    which is not what we want (it breaks our handy solution with deps
    in case of IPU.

[centos-ci]

Can one of the admins verify this patch?

[pirat89]

@vinzenz btw, i think we should stop prohibiting of the leapp rpm for fedora. As the CLI is already split, I think that nothing prevents to deliver the leapp tool under the fedora as well. WDYT?

[leapp-bot]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the
Leapp Guidelines and must pass all tests in order to be mergable.

If you want to re-run tests or request review, you can use following commands as a comment:

• leapp-ci build to run unit tests, copr build and e2e tests in OAMG CI
• review please to notify leapp developers of review request

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please consider rerunning the CI by commenting leapp-ci build (might require several comments). If the problem persists, contact leapp-infra.

[pirat89]

@vinzenz @Rezney I am going to check fully all results for el7, el8, fedora tomorrow. So far el7 builds are identical. But I need to check we get the expected results for fedora and rhel as well. - btw, I will drop tomorrow probably the limitation to build the leapp tool rpm just for rhel - so it is built on fedora too. Tell me wdyt about the changes or whether you have another ideas to make the specfile more simple / readable. I think that I will not get any idea now how to simplify it even more. (except the removal of commented parts, I will clean some comments after I am sure the building works on all build systems (el7, el8, fedora - we could hit yet some small differences on different build systems e.g. regarding the macro expansion, so i want to check it)

[pirat89]

currently the builds are broken. I am trying to figure out, why I cannot drop the python(abi) dependency - which has to happened, unless we fake it and tell we provide non-existing python-abi....- which is definitely no-go. The original workaround we used in the past is not working now for an unknown reason to me.

[pirat89]

@Rezney @vinzenz Finito. Ready for review. I squashed all commits. Currently the results should be unchaned on Python2.

To see easily all provides and requires for all packages, you can use this script (when packages installed, or modify it to work with downloaded rpms locally)

#!/usr/bin/bash

for i in leapp leapp-deps python2-leapp python3-leapp snactor; do
    echo "======================================================="
    echo "::::::::::: $i"
    rpm -q "$i" > /dev/null 2>&1 || { echo "SKIP" ; continue ; }

    echo ":: Requires"
    rpm -q --requires $i
    echo "--------------------------------"
    echo ":: Provides"
    rpm -q --provides $i
    echo "--------------------------------"
done

[Rezney]

What prevents us form updating it at once?

[pirat89]

@Rezney to be honest, I would need couple of hours to come up how to update the manpage, put the current stuff in the manpage to a new manpage provided by the leapp-repository, .... :) That's why we have the jira ticket about the documentation. However, I updated already the description to my best. Let's look at it guys, whether we could consider it as final or you want a changes. For now, I rather choose let's say a draft to focus on technical parts.