On Sunday, June 15, 2014 21:27:57 Peter Pentchev wrote: > Source: python-defaults > Version: 2.7.6-2 > Severity: wishlist > Tags: patch > > Hi, > > First of all, thanks for maintaining Python in Debian! > > As part of this year's "Bootstrappable Debian" Google Summer of Code > project I took a look at python-defaults to break a circular build > dependency as noted in the "Feedback Arc Set" section of > http://bootstrap.debian.net/amd64/ and, more specifically, at > http://bootstrap.debian.net/source/python-defaults.html and the > version-specific pages linked from it. There are two primary goals to > my work on this GSoC project: > - The first goal is to modify some packages so that they may be built in > some limited way ("nocheck", binary-only, or build profiles like > "stage1") without some of their usual build dependencies. In most > cases this is caused by one or more dependency loops between binary > and source packages, so that a source package requires for its > building, directly or indirectly, one of its own binary packages to be > already built. The modifications make the source build in a limited > fashion (not generating documentation, not running tests, not building > some of the binary packages) so that this may happen with only the > rest of the build dependencies, so Debian may be bootstrapped on a new > architecture starting from a very few cross-built toolchain packages > and then moving along, source package by source package. > - The second goal, which is actually closely related to the first, is > that in the process of modifications, any changes (some files not > regenerated, others not built at all) can be made with binary package > level granularity. This means that if a binary package is built at > all during a limited build, then it must have the same contents as the > same binary package resulting from a full build. The point here is to > avoid breakage if other packages in the archive depend on some > functionality provided by the omitted files; if so, it should be > obvious that the functionality is missing, and the clearest way to do > that is by omitting a full binary package or, rather, delaying its > build until the rest of the build dependencies are present. > > After this somewhat lengthy introduction, the point of my work on > python-defaults was to remove two circular build dependencies: > lsb-release and python-docutils, both of which require python to be > already present. It was very easy to drop lsb-release, since dpkg-dev > 1.15.1 and later provide the needed functionality in the dpkg-vendor > utility. > > With python-docutils the result was a bit more... unconventional than > I'd like. The usual way to resolve these circular build dependencies is > to make sure all the files that need more tools for generating are moved > to a separate package and this package is built conditionally. For > documentation files, this is usually very easy, as with libtasn1-6 in > #749854, autogen in #751470, flex in #749344 - in some cases it's as > easy as moving some packages from Build-Depends to Build-Depends-Indep > and slightly adjusting the rules file to only build the documentation in > build-indep/binary-indep. Well, with python-docutils this led to two > weird consequences: > - the Python Policy and the Python FAQ had to be moved from the python > binary package to the python-doc one, which meant that, to avoid > replacing the /usr/share/doc/python/python-policy.html/ directory with > a symlink to ../python-doc/python-policy.html/, I had to let > python-doc install stuff into /usr/share/doc/python/. I know that > this usually raises a few eyebrows, but it seems to be the cleanest > way to do it (dpkg does not seem to handle very well a directory being > replaced with a symlink during a package upgrade). > - the manual pages for the executable tools in the python and > python-minimal binary packages are also generated documentation, which > means that there was a choice: go with statically-generated versions > and make sure they are refreshed periodically, or move them to > python-doc, too. Well, moving them to python-doc leads to it now > installing manual pages for utilities in another package - another > "raise a few eyebrows" situation. > > I added a Recommends: python-doc to both python and python-minimal, so > that in the usual "recommended packages are installed by default" case > both the Python Policy and the manual pages will be present on the > system. Still, I realize that this is a bit fishy, and in the end you > have the final say as actual maintainers of the Python packages in > Debian, so... here are the proposed patches, let the critique begin! :)
This analysis does not seem to be entirely correct. Python policy is generated with debiandoc2text and debiandoc2html which come from debiandoc-sgml, so I think Python policy is irrelevant to this discussion. There are two kinds of man pages shipped in python-defaults: - idle.1 and pyversions.1. Neither of which are generated - dh_python2.1 pycompile.1 pyclean.1 which are generated and need docutils The latter set of manpages are unlikely to change. The copy of dh-python that is shipped in python-defaults is strictly legacy (development is now done in a separate dh-python package). As a result, I think it's perfectly acceptable for update of these man pages to be conditional on the availability of python- docutils. The man pages need to stay in the correct package even at some risk they might be slightly obsolete. I don't think adding python-doc (and thus python2.7-doc and its dependencies) to recommends is an acceptable solution. I don't personally have any objection to moving the FAQ to python-doc, but let's see if my co-maintainers have a different perspective. Scott K
signature.asc
Description: This is a digitally signed message part.
