On Wed, Dec 4, 2013 at 10:45 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
On Wed, Dec 04, 2013 at 01:34:14PM +0100, Thomas Spura wrote:
> On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda <bkabrda@redhat.com> wrote:
>
>     ----- Original Message -----
>     > Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
>     > > (tkinter is actually a subpackage of python itself)
>     >
>     > I guess you know what I mean here, but to be clear:
>     >
>     > tkinter is only an example, we got more, like pyserial, PyYAML...
>
>     Oh, I see. Some time ago, FPC has accepted a change that says, that
>     packages with "py" in name should be prefixed with "python-" anyway [1].
>     Since this only applies to newly created packages, we will have to cope
>     with this, unfortunately. So my idea of handling this would be:
>     - all packages must have Provides: python-*
>     - packages that weren't prefixed with "python-" previously (pyserial,
>     PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
>     Sounds good?
>
>     > Other thing:
>     >
>     > What about apps? Do we want something in the guidelines that would say:
>     >
>     >       If the app clearly works with both Python 2 and Python 3,
>     >       then the Fedora package is obligated to use Python 3 instead
>     >       of Python 2.
>     >
>     >       If however the app only works with one of them, obviously,
>     >       Fedora package uses and requires that one.
>     >
>     > Or do we keep that on the packager's decision?
>
>     Toshio already proposed a guidelines solution for this [2], but now that I
>     look at it, it seems that it never got proposed to FPC. Toshio, will you
>     propose that or should I? I guess we can do this regardless of the change
>     I'm proposing now.
>
>
>
> How about using "python" in that case? "python-*" should use the correct python
> version, whichever is enabled in the current Fedora release, so nothing should
> change for such programs.
>
> Take whaawmp [3] as an example and let's assume it works on python2 and python3
> out of the box. There is "python" everywhere, so when there is the switch from
> "python pointing to python2" to "python pointing to python3" (and similar for
> all python macros of course), a simple rebuild should be sufficient. Isn't it?
>
Timeframewise, we're most likely going to want to switch programs over to
/usr/bin/python3 before we switch /usr/bin/python over to point at
/usr/bin/python3.  So it would be best to keep these separate.  Also, if
"/usr/bin/python" gets injected into programs, there's a moderate to high
chance that they'll fail (many applications are still python2 vs python3
selectable at build time rather than at runtime).

That was my point. When /usr/bin/python is switched to point to /usr/bin/python3, then %{python_sitearch} also needs a switch to %{python3_sitearch} (and all other macros too) and the application can see at build time which python is around and build/work with that.

If a package maintainer wants to switch to python3 earlier, then (s)he can do so, but this use case from above would be automatic this way.

Greetings,
   Tom