* Radovan Garabik <[EMAIL PROTECTED]> [010726 18:49]: > On Thu, Jul 26, 2001 at 05:24:04PM +0200, Gregor Hoffleit wrote: > > Then, we still have to agree on a strategy how to set up the > > dependencies, in order to make the upgrade work in an intuitive way. > > > > For maintainers of Python extension modules, this would mean that they > > would have to build one package for each included Python version, e.g. > > python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb. > > > > Is there a reason for python1.5 existance _other_ then supporting > older application? If not, I'd propose to have packages named > python1.5-foo for python1.5, and python-foo for current > version of python (i.e. 2.1), and for packages that do not care about > python version.
You will have to do some work anyway for each new feature release, if you're maintainer of a Python extension package. When I release 2.1.1 packages, you'll have to change your packages in order to somehow make the stuff available under /usr/lib/python2.1/site-packages. According to python-dev, there are *no* serious Python things that do not care about the Python version. > (Personally, I'd HATE to 1) rename my package whose upstream > name is python-utmp, 2) maintain two versions of it. > Ok, I'll probalby have to... <sigh>) Another problem would be that every time a new feature version of Python is released (i.e. 2.1, 2.2), *I* have to rename the packages of the current Python version from python to pythonX.Y ;-). More important, the names python-base, python-tk etc. are already used in dependencies of potato packages. There are many Python extension modules in potato that have a dependency like "python-base (>= 1.5)", but install stuff in /usr/lib/python1.5/site-packages. If we ship python-base and python-tk 2.1.1-1 in woody, then a simple "apt-get install python-base python-tk" will render all these packages unusable. Seriously, as I wrote, I don't subscribe to that extreme pessimism that I felt on python-dev. I think we can come up with a solution like the emacsen setup that makes it possible and easy to write a package python-utmp that registers and installs for all installed Python versions. But, I'm afraid, we will have to use something like a registry. There's a discussion on the Distutils SIG as well about a Package DB (which I haven't followed). That sounds like something that might help us, too. But I'm afraid it's way too late to implement this for woody. Instead, for woody I would try to find a setup that's mostly neutral, that should mean it leaves us much room to move. That seems to be the case for the python1.5/python2.1(/python2.2) naming scheme, and that's why I would prefer it. > > There would be no python-* packages in woody!!! > > Why (even considering your proposal above)? If there is a package called > python-foo, which is pure python and works with both 1.5 and 2.1, should > there be 2 packages made of it? (different only in names) But how would a package look that works with 1.5 as well as 2.1 ? Would you install the stuff in /usr/lib/python2.1/site-packages, and use symlinks for all .py files in /usr/lib/python2.1/site-packages ? Or would you duplicate the .py files in both site-packages trees ? New problems arise when I would create (experimental) packages of Python 2.2a1 for developers, so that we have three different versions at the same time. The feedback from python-dev was that it's indeed possible that
