On Mon, 2012-08-13 at 03:09 -0400, Bohuslav Kabrda wrote:
----- Original Message -----
> On 08/06/2012 04:22 AM, Toshio Kuratomi wrote:
> > The only distribution that has switched is arch. When they did
> > there was
> > a big uproar about how arch was doing something wrong which
> > eventually
> > resulted in that PEP.
>
> Yeah, we mainly wrote PEP 394 in order to nudge *everyone else* into
> providing a /usr/bin/python2 symlink to help deal with Arch making
> their
> bold leap into the unknown (as well as going on record that we think
> switching it *right now* is still a bad idea). There's "bleeding
> edge"
> and then there's "tap dancing on razor blades in your bare feet" :P
>
> To be honest, I expect that the long term outcome will be that
> "/usr/bin/python" becomes solely the preserve of the OS, with all
> cross-platform scripts and applications using "/usr/bin/pythonX",
> software collections, or language level virtual environments.
>
> From an end user perspective, having things mostly compatible with
> both
> 2 and 3 should come *before* that symlink gets flipped rather than
> after.
>
> Cheers,
> Nick.
>
Ok, then I would suggest using Tom Spura's idea about making only
python2- and python3- packages (maybe with the virtual python-
provides for python2- packages, as Toshio has mentioned). We could
target this for F19 and we could also start helping various upstreams
with switching to python 3 and see where this will take us. Does that
sound good?
If we're looking at this kind of change (python2-foo and
python3-foo),
how about some other prefixes:
* python2-debug-foo (or somesuch) for a build of the package against
the --with-pydebug python2 package
* python3-debug-foo
* pypy-foo for the package built against PyPy
FWIW an old idea I had for revamping how we maintain Python packages can
be seen here:
http://lists.fedoraproject.org/pipermail/python-devel/2010-March/000213.html
with some further ideas here:
https://fedoraproject.org/wiki/DaveMalcolm/PythonIdeas
(you can tell that page is old, it still mentions Unladen Swallow and
Pynie...)
I still like the basic idea: introduce a tool that captures the info on
python runtimes for a given release in one place, and use it
programmatically within specfiles to avoid copy&paste. Although the
proposal isn't complete (how to handle exclusions?), I'm still fond of
it.
Another idea would be to use the Software Collections tool seen here:
https://fedorahosted.org/SoftwareCollections/
I known that people within Red Hat have been looking at using that in
the RHEL context, and some of that is likely to be appropriate for EPEL
too - though AIUI it's a shift in model from one build per src.rpm to
multiple builds per src.rpm
Hope this is helpful
Dave