I haven't sat down to respond before now, but I've been following the
entire discussion.
On Sat, Aug 16, 2003 at 11:07:26PM +1000, Donovan Baarda wrote:
| On Sat, 2003-08-16 at 00:20, Matthias Klose wrote:
| > Donovan Baarda writes:
| > > But that was kinda the point... you should be able to install a
| > > pythonX.Y package without python (X.Y). This way you get
| > > /usr/bin/pythonX.Y, but not /usr/bin/python. I don't see any reason why
| > > python2.3 needs to depend on python at all. You should only need python
| > > (2.3) depending on python2.3.
| >
| > IMO we want to have a way to ensure a specific version of python. I
| > don't know another way then having the dependency of python2.3 on
| > python.
|
| Check out the policy again... the entire point was if you want a
| particular pythonX.Y, install the pythonX.Y package... if you want the
| default python, install python.
|
| The pythonX.Y[-foo] packages should be self-sufficient and not depend on
| the default python. The python[-foo] package is a simple wrapper that
| depends on the default pythonX.Y[-foo]. Changing the default python
| should be a simple process of releasing new python[-foo] packages that
| depend on the new default pythonX.Y[-foo]. We had python2.3[-foo]
| packages before python (2.3)... there was no need to even release new
| versions of these packages to migrate to python (2.3).
|
| I fail to see what having python2.3 depend on python (2.3) gets you,
| apart from tangled.
I wholly agree with Donovan. Prior to python2.3 depending on python
(2.3) I had python2.3 and python2.2 (and 2.1, but that's beside the
point) all happily co-existing. Some libraries (such as wxPython)
only existed for one or the other version, and so I used it only with
that version of python. My system worked well, and even the
transition from python (2.2) to python (2.3) in the archive caused no
disruption in my system. It wasn't until python2.3 depended on python
(2.3) that I was forced to choose between keeping python2.3 and
keeping the other python-<foo> libraries I wanted.
| > > There might be occasions where you want to install something like zope
| > > that needs python2.1, but don't particularly want to install python. If
| > > python2.1 had "Depends: python (>=2.1)" then you couldn't do this.
| >
| > There is nothing that hinders you installing zope without python and
| > python2.3.
|
| Not right now, but thats because python2.1 never depended on python.
| Hence python2.1 can be installed without any other versions of python.
|
| by making python2.3 depends on python, you are committing your self to
| releasing a new python2.3 just to fix this IMHO broken dependency when
| we have python (2.4).
I agree here too.
| > > You can't just have python2.3 depend on python (>=2.3) so that it can
| > > use #!/usr/bin/python for compiling because what happens when we have
| > > python (2.4)? All the python2.3 modules get compiled with python (2.4)
| > > and mass breakages.
| >
| > As long as there are unversioned modules they should break. The
| > package maintainer should take care that they work (or we provide them
| > with a pyc-recompiler for a major version change).
|
| I'm talking about python2.3 breaking... not other unversioned packages.
| If you install python2.3 and python(2.4) then all of python2.3's *.py's
| will be compiled with python2.4.
|
| You are going to have to fix the python2.3 package when we migrate to
| python (2.4). If you didn't have this dependency then we could migrate
| to python (2.4) without having to release a new python2.3 package at
| all.
This point here really interests me. When 2.3 is not the default
version of python, then all scripts and stuff in python2.3 must use
/usr/bin/python2.3. From my perspective, it seems worthwhile to me to
make all those things use the versioned binary from the start so that
they don't need to be fixed later. If this approach is taken, then
the next question becomes why not remove the back dependency now and,
as Donovan says, eliminate the need to modify the python2.3 package in
the future (apart from upstream point releases, naturally).
| It is also making migration from python (2.3) to python (2.4) bumpier
| than it should be.
Just as it makes the current 2.2->2.3 transition less smooth for
cutting-edge users than it could have been.
| > > IMHO the original bug poster and Derrick were correct; all
| > > pythonX.Y[-foo] packages should be using /usr/bin/pythonX.Y explicitly
| > > everywhere, and that includes pythonX.Y itself.
| >
| > I don't agree :-) We should not set our focus on having the
| > possibility having more than one python version installed in parallel,
| > but on having one preferred version installed. If the transition is
| > done, you shouldn't care on the dependency anymore.
|
| Didn't we discuss this to death during the development of the Python
| Policy? Go back over the threads... the whole reason why it is what it
| is was so that people could have more than one python version installed
| in parallel.
I think having multiple python versions installed is very important to
debian. It is essential for developers, who need to test there code
on multiple versions and for developers of python itself who need to
determine when a particular behavior changed.
| And it was working well... Zope using python2.1 happily co-existed with
| python (2.2), and the transition to python(2.3) was going equally
| smoothly until suddenly python2.3 depended on python (2.3)
My complaint began with the back dependency. I fully understand that
some packages won't be updated as soon as the new python hits the
archive. That isn't the problem. The problem is when I can no longer
have all of the needed or desired python libraries installed. I was
content to stick with python (2.2) during the transition, until all
packages depending on python (2.2) were updated to (2.3). During that
same time I was using python2.3 for all new stuff and migrating
everything that was ready to be migrated. It was very smooth, until
the back dependency made it come crashing down.
| If everyone agrees that there is no need to support more than one
| version installed in parallel, then we can toss the whole
| pythonX.Y[-foo] packages and policy entirely. However, I suspect that
| there will be an outcry if you start doing this.
|
| > Remains your concern about the unnecessary installation of the default
| > version. IMO it's not soo bad, if you have the space to install zope
| > (and the data for the site) or jython (together with java).
I don't care whether or not I have the option of not having a default
python at all. The default python package is only a symlink or two
and a changelog.
This (rhetorical?) question has been lost in the trimming, but yes
this issue is really only an issue during a transition. (which is why
I didn't speak up immediately) After a transition is complete then
there is no issue because all python libraries will be available for
the current python. This is just a matter of making the transition
smoother for users of unstable who want the latest-and-greatest python
but may need (or want) various libraries that have not yet been
transitioned.
Since this discussion has become so drawn out, I just want to
explicitly say that I really do appreciate your work Matthias, I am
just disagreeing with one specific decision.
-D
--
[Perl] combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable.
It combines the power of C with the readability of PostScript.
-- Jamie Zawinski
quicker http://dman13.dyndns.org/~dman/
Attachment:
pgpLo5PfhjNMQ.pgp
Description: PGP signature