From Fedora Project Wiki

< User:Bkabrda

Revision as of 10:43, 10 December 2014 by Bkabrda (talk | contribs) (Created page with "== EPEL 7 in Python 3 Plan Draft == === Why Python 3 in EPEL 7, Why not SCLs === Due to Fedora plans for migration to Python 3 [1], it is becoming necessary to have Python 3...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

EPEL 7 in Python 3 Plan Draft

Why Python 3 in EPEL 7, Why not SCLs

Due to Fedora plans for migration to Python 3 [1], it is becoming necessary to have Python 3 accessible in some form in EPEL 7. This will allow upstream projects to move to Python 3 (dropping Python 2 support) and still be usable through EPEL repositories. Some key stakeholders in this regard are Fedora Infra and DNF.

Another important reason is further promotion of Python 3 and raising awareness for enterprise-level Python users.

Because of key stakeholders like Fedora Infra and DNF, SCLs as a solution to this problem were ruled out. SCLs are currently not allowed in EPEL (and it seems they won't be allowed in near future) and since these projects need/strongly prefer to be in EPEL itself, SCLs are not a viable alternative for them.

Some Facts

  • Python 3 is actively developed by upstream and new minor versions are released approximately every year. Latest Python 3 minor is 3.4.
  • Python minor versions are not ABI compatible, rebuilds are needed (both because of libpython soname change and because of bytecode magic numbers).
  • Python has a good support for parallel installable stacks, even for minor versions of one major version (e.g. 3.3 and 3.4 can easily be installable alongside).
  • EPEL policies try to discourage updates that break ABI and require rebuilds of other packages - due to the above fact, I consider Python minor version update a "major version update" as specified in EPEL update guidelines [2]. And as the guidelines say, this should be avoided if at all possible.


  • We will package Python 3 as python3X parallel-installable package (X is minor version, e.g. "4" ATM).
  • All extension packages will be named python3X-foo. They will follow Fedora's python3 packaging guidelines with the exception that name contains both major and minor Python version (in Fedora it's only major).
  • The whole python3X stack will be parallel installable with any other python3Y stack.
  • In a situation when python3X is in EPEL and 3.X+1 is released upstream, the following should happen:
    • python3X+1 package will be created for EPEL ASAP and all extension packages should be built also for this new python3X+1 stack. (While the python3X stack would stay untouched the whole time.)
    • When all packages are rebuilt for python3X+1, the old python3X stack will be retired after some amount of time (TODO: how long?, TODO: would this align with the EPIC proposal somehow?).
    • "/usr/bin/python3" will belong to the "stable" python3X stack, hence it should be only changed to point to the new stack once the old is obsoleted. Usage of "/usr/bin/python3" should be discouraged in favour of using /usr/bin/python3.X explicitly (TODO: or should we not provide "/usr/bin/python3" at all?)

Packaging Parallel python3X stacks

  • Automatic dependency generators and bytecompilation hooks should do fine.
  • SRPM/RPM naming:
    • As mentioned above, binary RPMs will be named python3X for Python itself and python3X-foo for extension packages.
    • Source RPMs should also be named python3X-foo.srpm, although we could create python3-foo.srpm and build python3X-foo.rpm and python3X+1-foo.rpm out of it. Doing the latter is pretty similar to what we're doing in Fedora with parallel python2/python3 stacks and may be easier to maintain. (We could even create just python-foo.srpm, but that might be confusing, since the same SRPMs could exist in RHEL/CentOS 7, which are used for the Python 2 RHEL 7 stack.)
  • Dist-git possibilities:
    • Having python3X-foo dist-git repo for every package. Easy and obvious solution, but packages would have to be re-reviewed and new repos created with every Python 3 minor release. This would align with the first SRPM variant (python3X-foo SRPMS).
    • Using current dist-git repos, e.g. branch epel-7 in python-foo (or python3-foo, if such Fedora dist-git exists). With this approach, we'd create python3-foo.srpm and build python3X and possibly python3X+1 RPMs out of it. The disadvantage is that some packages would be in python-foo and others in python3-foo dist git repos, which could get confusing. Also, their packaging could in time diverge a lot, so it might not make sense to do this.
    • Or we could do the above, but create special epel7-python3-foo dist-git repos to keep things more organized and separated from standard Python repos (I'd prefer this).

[1] [2]