Re: Experimental Python packages
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.
> It's a horrific can of worms, which is why perl in debian is no
> longer going to do this at all -- it's just not worth it. I
> encourage you python folks to think this through before adopting a
> similar scheme. Good luck!
>
> I think Python and Perl are similar enough that this advice applies.
> Also, I respect the Perl packagers enough to heed their advice.
Does Perl go through the same pains as Python with respect to how it
handles code breaking changes? It seems to me that a Perl upgrade is
more likely to result in breakage, Python wants to spit out warnings a
release before the code breaks... there is still a can'o'worms, but it
should not be horrific.
- Bruce
Reply to: