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?
Have a nice Sunday, :)
--
.''`. Étienne Mollier <[email protected]>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/3, please excuse my verbosity
`-
signature.asc
Description: PGP signature
