Re: Experimental Python packages
On Thu, Sep 06, 2001 at 05:27:18PM -0600, Bruce Sass wrote:
| On Thu, 6 Sep 2001, Neil Schemenauer wrote:
| > dman wrote:
| > > I think the admin should be able to choose which python implementation
| > > is referred to by /usr/bin/python independent of which python (or
| > > python-base if you prefer) packages are installed (the alternatives
| > > mechanism may be a good idea for this). There can be any number of
| > > reasons why an admin would want a certain implementation to be the
| > > default. These reasons could include
| > > o understanding a certain version & knowing it works (before
| > > upgrading and finding unexpected breakage)
| > >
| > > o Jython or Stackless
| >
| > Why can't the system admin use /usr/local/bin/python? Using
| > alternatives for /usr/bin/python is a stupid idea. I quote Joey Hess:
| >
| > The problem is, if you have two versions of perl (or python)
| > installed and /usr/bin/perl(python) is managed with alternatives,
| > dependancies are useless. A package that uses perl 5.6 (ptyhon 2.0)
| > features should depend on that package. But a user can install an
| > older version still, and can modifiy the alternatives to make it the
| > default, and then the program breaks, even though its alternatives
| > are satisfied.
| >
| > The only way to make a program that uses perl 5.6 (I'll stop putting
| > the equivilant ptyhon stuff in parens now :-) reliably work is to
| > make it use #!/usr/bin/perl-5.6. But this is just shooting yourself
| > in the foot when perl 5.7 comes out and your package works with it
| > fine except it refuses to use it because the filename is different.
|
| So the maintainer is going to have to upload new packages, where the
| difference between old and new may only be 1 character; if that is the
| only bit that needs fiddling then the maintainer is probably lucky,
| eh.
|
| If the admin does something like install (e.g.) 5.7 overtop of 5.6
| (--force-ing around dependency problems, or bypassing dpkg), the fix
| is as simple as linking 5.6->5.7... it is only a problem if perl-5.6
| disappears from the system, and then it is fixable with a link.
|
| As long as Deb-Py has packages derived from Python consistently use
| python<major>.<minor> in the #! lines, what bin/python points to will
| not matter and everything will just work. That is what I do when I
| build Python myself, and I don't have problems with Tools and
| accessories from Python-2.1.1 not working because python->python1.5.
| I have had a few problems when "/usr/bin/env python" programs expect
| python2.x, and python->python1.5; and I've been seeing a few warnings
| because /usr/local/bin/python->python2.2... being explicit in the #!
| line seems to be the best fix.
|
| Packages that depend on Python need to decide if they are version
| dependent or not. If they are, then it is in their best interest to
| be explicit about which Python they need so they don't get caught if
| someone changes bin/python on them (they will be rebuilding packages
| when the new version of Python comes out anyways). If they are not,
| then they will be testing against new Python's as they come out and
| only uploading new packages if they need to get version dependent.
I agree with Bruce that all packages should specify the version(s) of
python that they work with, then use that version explicitly to
execute. This way the package will always work regardless of what the
admin does with /usr/bin/python. Just suppose that I have an app that
needs 2.1, but uses /usr/bin/python instead. Now I do an upgrade and
/usr/bin/python becomes py3k. This app just broke! If it used
/usr/bin/python<version> instead then it would continue to work.
All python packages need to be retested at the very least when a new
version of python is released, and the depends/conflicts lines need to
be updated so changing the #! line is the least of a maintainer's
concern. I bet a clever maintainer could write a simple script that
patches the #! line automatically based on the depends line.
-D
Reply to: