[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New python policy



On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> * the dependencies (hopefully created automatically by dh_python) will
>   indicate the right interval automatically:
>   right now for example it would be "python (>=2.3), python (<< 2.5)"
>   for a package saying "XC-Python-Version: all"

What's the point of such a tight upper dependency? The whole idea was to
reduce the work for transitions, this still requires a rebuild when we
upgrade to Python 2.5 (or in fact, whenever the supported versions of
Python change).

Such information is necessary for extensions, but irrelevant for
programs or other modules.

> * the packages should provide all "python2.X-foo"
>   that they really provide (i.e. it must of course correspond to the
>   content of the package, which in turn should correspond to what
>   XC-Python-Version says). This Provides field can also be generated
>   by dh_python. (This is particularly relevant for binary modules of
>   course but it can make sense for non-binary modules as well, for example
>   if they don't support an old version anymore, stopping to provide
>   python2.3-foo would for example forbid upgrading a /usr/bin/python2.3
>   application relying on it)
> 
> For applications:
> * if they use /usr/bin/python, they should simply depend on python-foo
>   modules that they use.
> * if they use /usr/bin/python2.X, they should depend on python2.X-foo
>   modules that they use.

IMO use of python2.x-foo should be discouraged. Maintainers of
applications that need specific Python versions should ask maintainers
of the modules they need, and only the ones they need, to provide the
version-specific virtual package.

> For private modules (not sure here):
> * no change except that they can also use XC-Python-Version to get
>   a good python dependency automatically

See my first comment. This misses the point, if an application has to be
rebuilt whenever the Python version changes. Then all we get is a
precarious tower of tools to do exactly what we did before.

Given that we still have a ton of (virtual) python2.x-foo packages under
this policy, and any Python package would still need to be rebuilt
during a transition, I don't see how this policy does anything useful.
-- 
Joe Wreschnig <piman@sacredchao.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: