G'day, Hope you don't mind me Cc'ing to you guys. Let me know if you don't like it and I'll stop.
Quoting Matthias Klose <[EMAIL PROTECTED]>: [...] > Open issue(s): > > - didn't handle the conversion/recompilation of /usr/local python > packages. Some other questions; what happens with other packages that might/might not have installed stuff into /usr/lib/python1.5? Will they break? 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? > Tested with an upgrade from an uptodate unstable system. > > Please send feedback to ([EMAIL PROTECTED] and [EMAIL PROTECTED]) or to > this list. > > I didn't follow Neil's package schema, because it doesn't allow an > incremental transition from one version to the next. Compare the > python core libraries with something like libc5/libc6. We do have > separate dependent packages libfoo1 and libfoo1g to avoid upgrade > problems, so it's the the safe we to go. Another point in the > discussion was the upgrade to another python version. Sure, the old > package will stay (but won't hurt). New packages will be installed if > applications using the packages are installed. Remaining problem: you > only install the python packages for your own development, you will > have to select the packages manually. 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'd prefer it for all specificly python related packages, but it should be compulsory for at least parts of python proper. I know idle is a bit border-line, but it is part of the official windows python bundle. 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. 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. 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. 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). 4) Make python-base provide a symlink /usr/bin/python to /usr/bin/python1.5. This would establish python1.5 as the current default. 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. 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. 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. -- ABO: finger [EMAIL PROTECTED] for more information.
