[Debian-med-packaging] Bug#1146800: timg: ftbfs with openslide 4.0.1 in experimental

[Tobias Frost]

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 at 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