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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
