Am Sun, Sep 06, 2026 at 11:22:35AM +0200 schrieb Étienne Mollier: > Hi Benjamin, Hi Tobias, > > Benjamin Gilbert, on 2026-09-05: > > The fix in 4f724835ef doesn't make sense to me. OpenSlide doesn't expose > > any of its dependencies in its own headers, so there's no reason that > > specifically libdicom-dev and libsqlite3-dev should be dependencies of > > libopenslide-dev. This is just the usual problem that pkg-config uses > > Requires.private to mean both "packages needed for static linking" and > > "packages needed for header inclusion", which are very different lists. > > Surely the same logic should be applied to all OpenSlide -dev dependencies, > > one way or the other? > > Thanks for your remark, right now I'll stick to focusing on the > transition coordinated in #1146803, so that CVE-2026-54604 > finally gets resolved. In this context, 4f724835ef is mostly a > fix/workaround to avoid jamming the transition on build failure > of timg. > > Longer term, I would lean toward my initial idea that pulling > the extra components would be the responsibility of the reverse > dependencies, depending on their build requirements, be it due > to real usage of the headers, or due to constraints caused by > the build management system. I may be conflating two distinct > issues here, but the situation feels reminescent of #826048 > affecting gdcm. I'm not sure how you would want to move next: > > * the current situation is probably weird but okay for now; > * I still believe complementing timg build dependencies would > be appropriate, even if my actions from yesterday don't well > reflect that; > * I won't get in the way of complementing libopenslide-dev > dependencies if you believe this is the right approach, in > which case I'm okay to tackle a dedicated bug or apply a > patch. > > What do you gentlemen think?
Well, I think the issue is with openslide, not with timg. Let me try debugging it: openslide declares dependencies e.g. on sqlite in its package file. timg is not using sqlite at all. It is openslide that is requiring this dependency (and grepping timg source for sqlite yields an empty result, while for openslide it does not). Possibly the pc file shouldn't declare a dependency on sqlite if it does not need it? Maybe the bug is with the pc file? It might also be a bug with CMake's pkg_check_modules, but CMake upstream seems to disagree: https://gitlab.kitware.com/cmake/cmake/-/work_items/25692 Let's see what stock pkgconfig does (this is in a pbuilder chroot with timg build-deps installed): pkgconf --libs openslide ; echo result: $? Package glib-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `glib-2.0.pc' to the PKG_CONFIG_PATH environment variable Package 'glib-2.0', required by 'openslide', not found Package 'gio-2.0', required by 'openslide', not found Package 'gobject-2.0', required by 'openslide', not found Package 'cairo', required by 'openslide', not found Package 'libdicom', required by 'openslide', not found Package 'sqlite3', required by 'openslide', not found Package 'libopenjp2', required by 'openslide', not found result: 1 And this isn't specific to --libs: root@gondor:/tmp/buildd/timg-1.5.2# pkgconf --cflags openslide ; echo $? Package glib-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `glib-2.0.pc' to the PKG_CONFIG_PATH environment variable Package 'glib-2.0', required by 'openslide', not found Package 'gio-2.0', required by 'openslide', not found Package 'gobject-2.0', required by 'openslide', not found Package 'cairo', required by 'openslide', not found Package 'libdicom', required by 'openslide', not found Package 'sqlite3', required by 'openslide', not found Package 'libopenjp2', required by 'openslide', not found result: 1 So pkgconfig is unhappy, regardless of timg. I think the .pc file is wrong, or pkgconfig does some weird stuff. I thought Requires.private was only supposed to matter for static linking, so I'm not sure why pkgconfig is trying to resolve these dependencies for a normal --cflags/--libs query. To make sure this isn't somehow specific to timg, I made a minimal OpenSlide test program: #include <stdio.h> #include <openslide/openslide.h> int main(void) { printf("OpenSlide version: %s\n", openslide_get_version()); return 0; } It fails to compile/link with: cc -o openslide-test openslide-test.c $(pkg-config --cflags --libs openslide) because pkg-config fails to resolve the dependencies above. However, the exact same program links fine when using the library directly: cc -o openslide-test openslide-test.c -lopenslide So I don't think this is a timg issue. The OpenSlide library itself is linkable and its headers work; it is specifically the pkg-config metadata/resolution which is causing the failure. Looking at the generated openslide.pc, the relevant part is: Requires.private: glib-2.0 >= 2.56, gio-2.0, gobject-2.0, cairo >= 1.2, libdicom >= 1.3.0, sqlite3 >= 3.14, libxml-2.0, libtiff-4, libopenjp2 >= 2.1.0, libjpeg, libpng > 1.2, zlib, libzstd There is a distinction here between Requires.private and Libs.private: the former is precisely where dependencies which are only relevant to the implementation are normally expressed. So I don't think simply adding all these -dev packages to libopenslide-dev is necessarily the right solution either. timg doesn't use sqlite. It is only indirectly depending on it through OpenSlide's pkg-config metadata. I'd therefore suggest that we first determine why pkgconf is resolving Requires.private for a normal query, and whether the OpenSlide .pc file is appropriate for Debian's pkgconf semantics, rather than adding OpenSlide's entire set of private build dependencies to libopenslide-dev. -- Cheers, tobi
