Re: Debian Python policy.
[Please don't CC me, I'm on the list. I wish MUAs would respect the
mail-followup-to header.]
Donovan Baarda wrote:
> From archive updating point of view, my scheme has a large
> python-X.Y-foo added and a small python-foo updated when python
> upgrades. Your scheme has a large python-foo updated and a large
> python-X.Y-foo added, where python-X.Y-foo is mostly the same as the
> old python-foo.
By the time Python X.Y+1 comes out there is probably a micro release of
X.Y available.
> That is, if you actualy intend to produce python-X.Y packages... I
> suspect you wouldn't bother with your scheme.
Only if absolutely necessary. Does Potato need Python 1.6 or 2.0? I
suspect not. I'm not sure it even needs 1.5.2.
> Something that does complicate it all is even python modules that are version-
> independant become tied to a particular version when they are installed
> into /usr/lib/python-X.Y (as in your python-bar above).
That's not as bad as progams becoming version dependent (as happens in
your proposal). So far I have about 70 modules on my list that need to
be updated when python is updated. There are over 100 packaged programs
that use python. From my initial investigation it looks like most of
them will work fine if python becomes version 2.1.1.
> 3) have python-foo which depends on python (>=X.Y) install into
> /usr/lib/python, and install links in /usr/lib/pythonA.B/ to
> /usr/lib/python/* for all A.B >= X.Y. Note that these links will need
> to be updated every time a new python-X.Y or python-foo is installed.
> Perhaps a utility "update-links" function in the python (X.Y) package
> should be provided to do this.
>
> Note that 1) and 2) will break if a python upgrade changes the python
> byte- code. Only 3) is bytecode-change-resistant.
That won't work for extension modules. Also, bytecode is only
compatible between micro releases.
Neil
Reply to: