Bug#1124239: freetype: dependency loop with harfbuzz
Source: freetype
Version: 2.14.1+dfsg-1
Severity: serious
Justification: prevent testing migration until consensus is reached
X-Debbugs-Cc: debian-cross@lists.debian.org
User: helmutg@debian.org
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
Reply to: