Re: python again (was: Bug#225999: ITP: debsync -- installed packages synchronization tool)
On Tue, 6 Jan 2004, John Goerzen wrote:
> There are a lot of Python packages and Python modules in Debian that
> have counter-productive dependencies.
>
> Not only that, but Python policy tends to encourage such behavior
> (section 3.2, for instance.)
The section says that if you need a particular version of Python you
must explicitly use that version. Reads like "common sense" to me.
> Section 2.2.1 is totally, completely, utterly broken and stupid. If I
> ever run into situations where I need to make Python packages, I do it
> the right way (python-foo depends on python2.3-foo, and also build
> python2.2-foo) instead of the broken way. But for pure python programs,
> I just use python-foo and install them in /usr/lib/site-python.
It does seem awkward to need to explicitly pick a version if you want
to only support the default version (whatever it may be). Although it
does make sense if you expand the scope of "python" to include all of
Python and not just the-Python-in-Debian.
> Anything else is silly.
>
> > (Incidentally, a major reason to allow several versions of Python on the
> > same system is specifically to make it easier to test your programs on
> > several versions of the implementation to make backports *easier*, not
> > more difficult.)
>
> However, I'm not sure this has actually been accomplished. I think it
> would be better for Python in Debian to follow Perl's lead and have only
> one version present at a time. Python's backward compatibility actually
> seems to be better than Perl, in general, and so this should not pose a
> problem for us.
For that reason (Python's interversion compatibility record), it is
more important to support multiple versions of Python than it is to
support multiple PERLs. I suspect that if you could graph #users vs.
version# for PERL and Python you would get something along the lines
of a spike at the current release and a broad hump around the two
previous current releases, respectively.
It sounds like the problem is with how the dependencies are being
handled, and not with the existence of multiple versions of Python. If
the logic of the policy is sound and well expressed but also awkward,
counterintuitive, difficult to implement manually, etc., then it
should be codified (literally, along the lines of make-kpkg, with
dh_make's help, ???)
- Bruce
Reply to: