Source: freetype Version: 2.14.1+dfsg-1 Severity: serious Justification: prevent testing migration until consensus is reached X-Debbugs-Cc: [email protected] User: [email protected] Usertags: rebootstrap
freetype added a new build-dependency on libharfbuzz-dev. On the surface, this looks great. Unfortunately, freetype is part of the build-closure of build-essential and therefore part of architecture bootstrap and must be careful about dependencies being added. The dependency poses several problems. While freetype now Build-Depends on libharfbuzz-dev, harfbuzz already Build-Depends on libfreetype-dev. This is a cycle. Which one is supposed to be built first? At this point you can no longer build either of them without the other. This breaks both native and cross bootstrap. harfbuzz comes with a pile of dependencies on its own. In particular, it depends on gobject-introspection. We have not yet found a way to make that work without qemu and qemu is typically not available during early architecture bringup. Additionally, the meson maintainer is reluctant to support cross compilation involving gobject-introspection #1060838. Adding harfbuzz would add the following packages to the bootstrap set: * cairo (also depends on freetype) * chafa (also depends on freetype) * graphite2 * libavif * librsvg (depends on freetype and harfbuzz, another cycle) * tiff * dav1d * libwebp * libyuv * mesa (depends on lots, does not cross) * jbigkit * lerc * giflib This list is incomplete, but its length already hints at adding harfbuzz being a very bad idea though that librsvg <-> harbuzz cycle needs solving independently. I hope we agree that there is a problem that needs solving. Therefore, I tentatively set severity serious. That shall keep forky bootstrappable. A quick way forward would be configuring with --without-harfbuzz for now and take more time to come up with a better solution. I note that the udeb is still built --without-harfbuzz, so this likely still works. I'm not sure how harfbuzz is exposed to client dependencies. Possibly adding a pkg.freetype.noharfbuzz build profile is all that is needed. Then we might perform a build of freetype without harfbuzz, build all the other pieces and then rebuilt freetype with harfbuzz later during a bootstrap. The question arises though how other packages can indicate that they need a freetype with harfbuzz support. Maybe libfreetype-dev could provide a virtual package libfreetype+harfbuzz-dev unless the profile is in effect and then other packages could additionally depend on this when they need the harfbuzz functionality. I appreciate other perspectives on this issue as I quite likely do not see the whole picture. Helmut
