New python policy

Hello everybody,

there has (again) been some grumblings about the python transition (hi
Thomas!). The python Bof at the debconf has been successfull at deciding a
new python policy. However this policy is not implemented yet. That's what
causing this delay...

The new policy is more or less the following (people may correct me if I'm
wrong):
The major changes are for packages providing public modules:
* they should support all current python versions (the set of supported
python versions is defined by the python-all and python-all-dev packages)
* the same packages should indicate via an XC-Python-Version field in the
debian/control file (source paragraph) the python versions that they
support. This field can be either a list of supported versions ("2.3,
2.4") or an interval (">= 2.4" or ">=2.1, <<2.4") or "all" (if no
restrictions are known).
* 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"
* 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.

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


As you can see, the bulk of the work is:
- modifying the rules file to build all versions for binary modules
- implementing the dh_python changes

Note: The policy doesn't require pycentral or python-support. But both of
these tools help to achieve the multiple-version support with a single
copy of the .py files.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-python-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Joe Wreschnig writes:
> 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.

No, see my posting from February. If a module depends on an extension,
it has to have this strict dependency.

> > * 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.

correct, but for those applications we try to include support for all
supported python versions in python-foo.

> > 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.

only if the application uses a non-default python version.

> 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.

see my slides from Debconf.

- we are able to make a transition with one upload (python-defaults)
- no extension modules need to be uploaded for a transition
(potentially depending on new shlibs).
- all rebuilds/uploads can be handled by bin-NMU's.

that sounds pretty useful.

Matthias

http://people.debian.org/~doko/pycentral/


--
To UNSUBSCRIBE, email to debian-python-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org