Re: python2.1 et al.
* Radovan Garabik <garabik@melkor.dnp.fmph.uniba.sk> [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
Reply to: