On 08/15/2013 10:19 PM, Christian Boltz wrote:
Hello,
Am Donnerstag, 15. August 2013 schrieb Sascha Peilicke:
On 08/15/2013 03:47 PM, Claudio Freire wrote:
On Thu, Aug 15, 2013 at 10:15 AM, Sascha Peilicke wrote:
On 08/15/2013 02:16 PM, Christian Boltz wrote:
Are there plans to make the /usr/bin/python symlink managed with update- alternatives? If yes, this will open an interesting can of worms ;-)>> I'm a bit surprised this isn't the case already.
So I'm gonna fix this ASAP :-)
I'm not sure if this is a good idea, see below for details.
In fact, I'm not a big fan of using alternatives. Both versions aren't so easily switchable. I happen to agree with the can of worms thing. The only thing needing u-a is the /usr/bin/python binary (and probably the man-page). Of course we ship a lot of Python software with she-banks like "#!/usr/bin/python" or "#!/usr/bin/env" python. Whenever one of those just accepts one specific major version, it needs adjustment.
So I would like to u-a the "python" and "python3" package with the latter having a higher priority (thus being the default). Software that insists on the old Python-2.7 can be fixed to use #!/usr/bin/python2 instead. On the other hand, most upstream codebases actually run on both, so it's not going to be a big issue.
Let me explain what I meant with "interesting can of worms" ;-)
The biggest "worm" are dependencies:
Assume a package currently comes with Requires: python-whatever because a python script in this package contains import whatever
For python3, you'll instead need Requires: python3-whatever
(Of course, py2 won't find installed py3 modules, and py3 won't find installed py2 modules because they are installed in different paths.)
Now tell me which Requires: line I have to write in the spec when the user can easily change the python version behind my back (and without telling the package manager)...
It depends with which Interpreter your script is invoked. If it depends on a specific ABI version, it is wrong to rely on /usr/bin/python pointing to the right thing. On the other hand, u-a allows for defaulting to other implementations in the future. We have already working packages for pypy and could use it as the default for the Python-2.7 ABI (instead of cpython). It's much faster you know ;-) But I acknowledge that people are used to /usr/bin/python being cpython-2.x, so it could be surprising that this isn't true anymore. So maybe it's better to stay with the current solution for the time being. I really wonder how this was done in the past, if at all.
Hint: the only guaranteed working option is to add py2 _and_ py3 requires, but I doubt this is what we want ;-)
I doubt that too.
Let me step back a bit from technical details. At some point we have to make Python3 the default. Some bumps are expected while doing so. Now is the right time to do it.
I'd say the dependencies are a quite big bump ;-)
BTW: for AppArmor, I think I have a decision: I'll create only py3 packages for the libapparmor bindings.
Well, there's an exception: for 12.2, I have to create a py2 package because swig is broken for py3 there [1] and I somehow ;-) doubt someone wants to fix swig on 12.2 (tell me if I'm wrong ;-)
There is always room for contributions *g* -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)