[Python-modules-team] Bug#577725: python3-docutils

[Jakub Wilk]

unblock 577725 with 573560
thanks

It doesn't look like python-support is going to support Python 3.X, but 
we can use dh_python3 instead.

In order to add support for Python 3.X, I'm going to split 
python-docutils to the following 4 packages:

python-docutils:
- ships Python 2.X modules
- provides /usr/bin/* binaries via alternatives
- depends on "docutils-common"
- recommends "docutils-doc" (to be demoted to suggests in wheezy+1)

python3-docutils:
- ships Python 3.X modules
- provides /usr/bin/* binaries via alternatives
- depends on docutils-common
- suggests "docutils-doc"

docutils-common:
- ships /etc/emacs/site-start.d/50python-docutils.el,
/usr/share/emacs/site-lisp/rst.el, and some common data files 
(templates, etc.)
- recommends "python-docutils | python3-docutils"

docutils-doc:
- ships documentation
- recommends "python-docutils | python3-docutils"

Dear co-maintainers, what do you think? Does it sound sensible?

After the split, packages that currently (build-)depends on 
"python-docutils" and uses only its command-line iterface could relax 
their (build-)dependency to "python-docutils | python3-docutils".

Some open questions:

- "python-docutils | python3-docutils" is a bit cumbersome to type, 
maybe both packages could provide a common virtual package (say: 
"docutils")?

- What about existing virtual packages? python-docutils currently 
provides docutils-writer-manpage, docutils-writer-odt, python-odtwriter, 
rst2man, rst2odt. The odt ones are unused, there are 3 reverse 
build-dependencies for man ones. I'm a bit tempted to drop all of them 
entirely.

-- 
Jakub Wilk