Control: tags -1 pending Hi Peter, Johannes,
I have been preparing a new upload of freetype to Debian unstable, and was about to include these patches. I am very much a fan of bootstrappability of the archive, and would like to help move this forward. However, I have to say that it's been very difficult for me to independently verify that these are correct changes that will facilitate cycle-breaking and bootstrapping. In bug #752270, Peter refers to the "Feedback arc set" section of http://bootstrap.debian.net/amd64/ . Reviewing the information at <http://bootstrap.debian.net/amd64/#fas>, I find no references to freetype at present. I do find freetype included in the full listing for SCC #1 under "Amount of Cycles through Edges", but this only shows that freetype has build-dependencies on docbook-to-man and libx11-dev (which I know), it doesn't show me how these dependencies are involved in a cycle. The docbook-to-man cycle, I'm able to work out for myself manually: freetype build-depends docbook-to-man depends opensp build-depends poppler-utils build-depends freetype. This seems to be a false cycle because docbook-to-man depends on sp | opensp, and sp does not build-depend on freetype. The libx11-dev cycle, I do not see where the cycle is when I eyeball the dependencies. So I was hoping to easily be able to find this information in the linked bootstrap reports. Peter then links to <http://bootstrap.debian.net/source/freetype.html>. This page doesn't provide much information at all - just a table of versions and architectures (is an x good or bad or does it just mean information is available?) and a link for version 2.5.2-4. If I follow that link, I see it takes me to <http://bootstrap.debian.net/source/%5B%5Bu'gnat-4.6',%20u's390x',%20u'4.6.4-4'%5D%5D_2.5.2-4.html>. This is obviously incorrect. If I manually correct the URL to <http://bootstrap.debian.net/source/freetype_2.5.2-4.html>, I get a page that includes a list of "cycles", but only shows 10 of these by default (out of 236). And the first 10 cycles it lists are all about opensp again. Finally, after asking for 100 rows at a time, I start to see some relevant information which starts to make sense: src:freetype ⇢ libx11-dev → src:libxdmcp ⇢ w3m → src:w3m ⇢ libimlib2-dev src:freetype ⇢ libx11-dev → src:libx11 ⇢ w3m → src:gpm ⇢ texlive-base src:freetype ⇢ libx11-dev → src:libx11 ⇢ w3m → src:w3m ⇢ libimlib2-dev src:freetype ⇢ libx11-dev → src:libxcb ⇢ python-xcbgen → src:python2.7 ⇢ blt-dev src:freetype ⇢ libx11-dev → src:libx11 ⇢ w3m → src:w3m ⇢ libimlib2-dev src:freetype ⇢ libx11-dev → src:libxcb ⇢ python-xcbgen → src:python2.7 ⇢ tk-dev src:freetype ⇢ libx11-dev → src:libxcb ⇢ python → src:python2.7 ⇢ tk-dev src:freetype ⇢ libx11-dev → src:libx11 ⇢ w3m → src:gpm ⇢ texlive-base src:freetype ⇢ libx11-dev → src:libxcb ⇢ python → src:python2.7 ⇢ xvfb The report then starts to show some repetition, with cycles that have been listed previously shown again but listed separately for different architectures for no visible reason. Some of these cycles make sense. libimlib2-dev, I recognize as a reverse-dependency of libfreetype6-dev. But many of the others do not. It appears that even here, the information about the cycle has been *truncated* to only show the first 6 packages in the cycle. texlive-base, blt-dev, tk-dev, xvfb do not depend on freetype. So it's very difficult to interpret the provided information to understand where the cycles are, to understand why freetype is the right place to make the change. In the end, I have satisfied myself (by manually testing with apt) that enough of these package cycles are real that yes, freetype should have a build profile, and I will therefore be applying these patches in my upload. However, as someone who does care about bootstrappability, I wanted to give you this feedback about the difficulty I had finding the pertinent information. As I commented from the audience during the bootstrapping talk at this year's DebConf, I think success in making Debian bootstrappable will heavily depend on being able to surface the required work in a way that is parallelizable across all Debian maintainers. I think this experience shows just how far we are from that currently, if it takes me this much effort to confirm the cycles when someone else has /already/ done the work of identifying it and supplying a patch. Please let me know if there is some other forum where you would like me to raise these concerns. I would very much like to see this cycle information exposed in a way that I can dive into it. BTW, along the way I made a few changes to the provided patch to debian/rules. - Your patch excludes the ft2demos from the unpack and patch targets based on the build profile. I disagree with this; I realize that it makes the build faster and this might be useful during the critical path of a bootstrap, but I think the unpack+patch stages of the build should always behave consistently and that this is more important than the optimization. So I omitted these parts of the patch. - Your patch keys on the value of the DEB_BUILD_PROFILES environment variable to determine whether to try to build ft2demos. You may notice that elsewhere in debian/rules, I am already using dh_listpackages to omit various packages if they (for whatever reason) are not being built. I've therefore changed debian/rules to use this consistently, as in: ifneq (,$(filter $(demospkg), $(shell dh_listpackages))) dh_auto_build -D $(ft2demos_u) -- TOP_DIR=../$(freetype_u) \ OBJ_DIR=../$(freetype_u)/objs endif This relies on the behavior of debhelper to properly omit the package from dh_listpackages when building with a build profile. However, we build-depend on that version of debhelper anyway for debian/control syntax compatibility, so I don't think that's an obstacle. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
