Re: Python Policy suggests dependencies that prevent installation
Hi,
(I've opened a bug report against the Python Policy now, please Cc:
379455@.)
On Sun, Jul 23, 2006, Steve Langasek wrote:
> Are we talking about the case in which /usr/bin/python is still << 2.4, or
> are we talking about what such packages should do Coming Soon?
The policy paragraph I want to fix is about packages which need a
particular Python runtime, for example packages needing 2.4 right now,
but it also applies to packages which will need a particular runtime in
the future, such as needing 2.3 when 2.4 is the default, or needing
2.5.
The problem does not affect all these packages, since the problem I
care about happens when a real pythonXX-foo package is installed on
end-user machines, but doesn't exist in the archive anymore. The
new python-foo package providing pythonXX-foo won't be installed if
apps only depend on the installed pythonXX-foo packages, but only if
one app depend on python-foo, or a pythonYY-foo which is not installed
but is provided by python-foo.
> For the former, no, it's not the business of end-user packages in general to
> attempt to force obsolete versions of dependencies off the system when
> they're functionally compatible.
I consider this breaks expectations and is dangerous. One of the
expectations it breaks is that an update doesn't let you have the
latest versions of software. Another one is that after an update, you
keep packages installed that have no corresponding source in the
archive anymore (but no removal at the ftpmasters level happened).
Another one is that I expect people upgrading from etch to etch+1 to
have software in versions of etch, not in versions prior to the release
of etch, but this problem creates a situation where one might upgrade
from pythonXX-foo before etch to python-foo etch+1. etc.
Given that we recommend the double depend in cases where a particular
version is needed, it seems quite reasonable to recommend it in all
cases instead.
Bye,
--
Loïc Minier <lool@dooz.org>
Reply to: