Re: multiple pythons and the default
On Sun May 7 2006 10:49, Martin v. Löwis wrote:
> Bruce Sass wrote:
> That impression is incorrect. There was a technical reason when the
> default was defined: it was the most recent version that tat time.
> The next default will have the same property: it will be the most recent
> release. So the decision what Python version is the default is *not*
> arbitrary.
ok
> > Therefore it should be possible to choose any Python as the
> > default so long as the dependencies of any package depending on the official
> > default Python can be satisfied, and any problem encountered in doing so
> > would be problems with the implementation of a "default".
>
> That conclusion is false, or at least misleading. A package depending
> on the default version might not just depend on other packages that the
> default Python would have to provide - it also might depend on the
> specific behavior of the default Python version.
Of course, sorry I probably could have been clearer. To me, a dependency on
a specific behaviour is a dependency on the software providing that
behaviour. So, naturally, either the new default behaves the same as the
current interpreter where it matters or the packages depending on
the old behaviour need to change.
So, ya, it could be misleading.
> > Debian's support for multiple interpreters should be more than a
> > convenient apt-get install some other Python interpreter, it should be
> > the infrastructure necessary to manage multiple Pythons. Consider that if
> > the system is designed so that an admin can easily change the default
> > Python, then Debian can also.
>
> What system is designed so that an admin can easily change the default
> Python?
None that I am aware of, and anyone dong that sorta thing shouldn't need
Debian's help/interference, but that's not the point.
If the system is designed so that an admin can easily change the default
Python, then Debian can also.
> > If a package depends on Python-2.4 then it should actually depend on
> > python2.4 and not some other package which just happens to pull in the
> > necessary interpreter...
>
> Why? This will give you many unnecessary hard-coded package
> dependencies. Packages that are reasonably expected to work with this
> current version and any future version should depend on the default
> Python.
Why unnecessarily depend on a specific version of Python (the current
default) if the code is expected to work with any future version, you
should be depending on any version of Python. Afaict, it is this pretending
to be version independent while actually depending on a specific version of
Python which is causing the upgrade problems.
Is it not the case currently that when Debian changes the default
Python...
"""
2.2.1 Support Only The Default Version
Name your package python-foo. This kind of package is called a default
module package. Install your modules into /usr/lib/pythonX.Y/site-packages/.
Make your package dependency look like
Depends: python (>= X.Y), python (<< X.Y+1)
Note that this kind of packaging means that your package will trigger a
conflict when the default Debian Python version in the distribution is
changed, and that you will have to provide a new version as soon as
possible, since the package will block the upgrade of python.
"""
..so, in fact, there is already a hard-coded dependency on which version of
Python is required by packages depending on the default Python, I am only
suggesting it be put more up-front.
Maintainers would still need to rebuild everytime the default changes, and
would have the additional task of changing #! lines, but nothing should get
held up if someone is slow or MIA.
Or am I wrong, and it is actually a good thing that a single package can
hold up a transition in this manner?
I get the impression that easier/faster/allowed (whatever the recent change
was) bin NMU's is seen as a particularly good thing for Debian-Python, but I
thought NMU's were generally considered a last resort tactic... is it a good
thing that Debian-Python appears to be relying on a last resort.
- Bruce
Reply to: