Dne 11.9.2012 12:09, Michal Vyskocil napsal(a):
On Mon, Sep 10, 2012 at 07:53:37PM +0200, Jan Matejek wrote:
I personally like the gcc approach more - they have one gcc package, which just maintain symlinks to the correct gccx.y version
To illustrate it more
python2 Provides: python = %{version}-%{release} # so zypper in python will select this package Obsoletes: python = some-version
Requires: python27
/usr/bin/python -> /usr/bin/python27
python3
Requires: python33
/usr/bin/python -> /usr/bin/python33
This would mean a conflict between python2 and python3 though. i'd like to avoid that. It does make sense to make it this way for /usr/bin/python2 -> python2.7 and /usr/bin/python3 -> python3.3 - then python apps can use #!/usr/bin/pythonX and be reasonably confident that they are running on the intended python version. I realized another thing: having "python" as an alias for either python2 or python3 could break packages if the user switched from python2 to python3 systemwide. We would have to change most python2 packages to use #!/usr/bin/python2 shebang, instead of just python. But this wouldn't have to be done all at once - we would state that switching system python to python3 is possible but unsupported, and change the packages gradually.
I am not sure if it's sane to have /usr/lib/python/site-packages -> /usr/lib/python3.3/site-packages or if the python-central is intended to do the same.
i'm not sure /usr/lib/python was ever used for anything else than lazily written install scripts ;e) so i'd probably just drop it and see what breaks. python-central would probably live in /usr/share/pyshared, for consistency with Debian. Who knows, at that point we might be able to convince upstream and FHS that it is -the- place for python modules
BTW: there are new features pyc repository directories and abi version tagged so files - are those already included in your proposal? http://docs.python.org/py3k/whatsnew/3.2.html#pep-3147-pyc-repository-direct...
yes, this is what allows us to implement the python-central approach without debian's symlink craziness
http://docs.python.org/py3k/whatsnew/3.2.html#pep-3149-abi-version-tagged-so...
And no, I don't think this is useful for us, at least not at this time. While it's easy to generate all necessary .pycs at install-time, we can't do that with .so files. And as long as different versions of the .so module are in a package at build-time, we can as well install them into their respective site-packages directories. (building such package would be fun, too)
Regards Michal Vyskocil [snip]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org