[EPEL-devel] Python 3 discussion

[Orion Poplawski]

This is a followup to the EPEL IRC meeting discussion about python 3.  I had a
couple questions which led me to take Slavek's excellent work and try some
changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3

Main ideas:
- (bikeshedding) - I didn't like the wording "other", so I went with "next".
- I didn't like having to toggle a macro in the spec files, I'm lazy
- What happens on the user's end?

So:

Lifecycle of python3X stacks, rebuilding:

    when a new python3X+1 is built in EPEL - let's say that there is python34
and python35 has just been introduced:
        A new python3-pkgversion-macros is build defining the %python3_next*
macros.
        (scripted) mass rebuild is run to build as much of the new stack
possible automatically.
        At some point /usr/bin/python3 is switched from python34 to python35.
        at a certain point at time an announcement is made that python34 is to
be retired and python35 is to be *the* one. At this point:
            python3-pkgversion-macros is rebuilt removing the %python3_next*
macros.
            python35 is rebuilt defining the normal %python3_* macros
            all python34 packages are retired

        At this point all packages build just python35-X subpackages



What I still don't understand is what this looks like on the user end, how do
they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like this
should be as automatic as possible.  So shouldn't they still use
/usr/bin/python3 rather than /usr/bin/python3X so they get updated automatically?

What about all of the old python34 packages left on their systems after
retirement?  Is there some way they can get cleaned up automatically?

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                   http://www.nwra.com