Source: libdrm
Version: 2.4.82-1
Severity: wishlist

Currently, libdrm is involved in build dependency cycles such as:

libdrm Build-Depends on valgrind
valgrind Build-Depends on gdb
gdb Build-Depends on texlive-base
texlive-base Depends on texlive-binaries
texlive-bin Build-Depends on libgd-dev
libgd2 Build-Depends on libtiff-dev
tiff Build-Depends on freeglut3-dev
freeglut Build-Depends on libgl1-mesa-dev
mesa Build-Depends on libdrm-dev

As far as I can tell, it should be sufficient just to annotate the
Build-Depends with "valgrind <!nocheck>".

Really?  There seems to be quite a bit of code that's conditional to
#ifdev HAVE_VALGRIND, e.g. in intel/intel_bufmgr_gem.c, and I don't
think building with the nocheck profile should alter the produced binary
packages.

Cheers,
       Sven

Hmm, I guess if it's indeed the case that it's generating valgrind
support stub assembly, or something along those lines, then it might
get more complex.  It might be necessary to produce libdrm2-stage1
etc. packages with shlibs/symbols set up to generate dependencies on
"libdrm2 | libdrm2-stage1".  Either that, or break the cycle somewhere
else, for example maybe by having valgrind able to produce a
valgrind-stage1 package without the correct gdb path encoded in.

Hi,

I think this was fixed by gdb qualifying its build-dependency on texlive-base
with <!nodoc>, wasn’t it? That way gdm is bootstrappable which breaks the
cycle.

Regards,

Stephen