Donovan Baarda writes: > Some other questions; > > what happens with other packages that might/might not have installed > stuff into /usr/lib/python1.5? Will they break?
No. However the priority of the python alternative from 1.5 should greater than the prio of the pyton from 2.x (at least for some intermediate time). > What is the plan for > these packages to support 2.x python? How are version independant > python addons going to be supported for all/latest versions of > python? I have only looked at the Packages.gz file so far, but > which of these packages include /usr/bin/python, or is there only > /usr/bin/pythonX.X? Not yet addressed. Writing something comparable to the emacs registration should work for all binary-indep packages: - install these files into /usr/lib/python/site-packages (do not include this in sys.path. - symlink each file in /usr/lib/python/site-packages to each file in /usr/lib/pythonX.Y/site-packages (for all X.Y). - compile all .py files in /usr/lib/pythonX.Y/site-packages (for all X.Y). - installing a new python version would do this for all already installed packages. How safe is this schema for arch dependent packages? > I notice that you have idle-pythonX.X instead of pythonX.X-idle. Any > particular reason for that? Can we decide on a convention for this > at least? I prefer pythonX.X-idle myself. Putting the python bit > first means they naturaly cluster together in sorted lists. I don't care. Probably Gregor called it this way, because it is an applicaton, not a library. > You also have pythonX.X-base provides pythonX.X instead of just a pythonX.X > package. Is there any benefit to this? It seems like a small bit of added > complexity for no particular reason. so the user doesn't expect the whole python installation if he installs python-base? > Do things like python2.1-mpz and python2.1-tk really depend on > python2.1-base (=2.1.1-0.2), or would they work with python2.1-base > (>=2.1.1-0.2) like python2.1-examples? IMHO it is a good idea to > avoid having to upgrade packages just to adjust the dependancies if > at all possible. mpz and tk are arch dependant, examples not. > There are some small changes that would make these packages be a > hybrid between a purely versioned python and Neil's scheme. Like the > following; > 1) Make the packages python-dev, python-doc, python-elisp, > python-examples, python-gdbm, python-mpz, python-regrtest, > python-tk, python-xmlbase and python- idle more than just transition > packages. Make them also function as wrapper packages that pull in > and establish one particular version of python as the default. > 2) Add a package python-idle (or idle-python) similar to existing > idle package. seems to be a mistake. should be idle instead of idle-python. Probably a good idea to rename this the new packages to idle1.5 und idle2.1 > 3) To python-dev, python-doc, python-examples, python-gdbm, python-mpz, > python-regrtest, python-tk, and python-idle add Depends: python-base (=1.5.2- > 17.0.2). why is this necessary? > 4) Make python-base provide a symlink /usr/bin/python to > /usr/bin/python1.5. This would establish python1.5 as the current > default. could be done with alternatives. > When everyone is ready to make python2.1 the default, new > releases of the python-dev, python-doc, python-elisp, > python-examples, python-gdbm, python-mpz, python-regrtest, python- > tk, python-xmlbase and python-idle wrapper packages can be released > that all have "Depend: python-base (=2.1.1-1), python2.1-xxx". The > new python-base would provide a symlink /usr/bin/python to > /usr/bin/python2.1. you would need this schema for each python-dependent package... > This allows other packages to depend on just python-base, > python-gdbm, etc if they just want to use the default version of > python. Packages that want to use a particular version of python can > depend on pythonX.X-base, pythonX.X-gdbm, etc. python-foo would depend on python-bar and python-baz. python-bar is available for 1.5 only, python-baz for 2.1 only. The dependencies are fulfilled ... > For true transperant support of version-independant packages we > still need to resolve the issue of where they put their files and > how they get compiled. My solution is to have them put their files > in /usr/lib/python, and have python- base provide a script that > creates and compiles symlinks to them in all /usr/lib/pythonX.X > directories. I guess this should probably also support /usr/local/ > python stuff. Send in you scripts ;-)
