Bug#1019485: libvirglrenderer-dev should depend on libva-dev
Ok. This package appears to lack some love. Bugs are never closed (I just closed a few bugreports which were fixed years ago), migration status apparently is never checked, bugs actually are not watched/handled (these 2 bugs are here for quite some time already). I pinged the maintainer but he didn't respond. I just uploaded virglrenderer package with current issues fixed, so things can be unblocked. Longterm, I'm fine to move this package under qemu umbrella (especially since it is relevant mostly for qemu these days). Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
According to the FAQ at
https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq :
My library z uses libx internally, but does not expose libx data types in its
public API.
What do I put in my z.pc file?
Again, add the module to Requires.private if it supports pkg-config. In this
case,
the compiler flags will be emitted unnecessarily, but it ensures that the
linker
flags will be present when linking statically.
So it is a common practice to add stuff to Requires.private, and it is not a
good idea
to ask upstream not to do that. With meson (as it is a case here), it
generates this
Requires.private automatically.
So it looks like removing this tag at install time is the way to go after all,
unless meson grows an easy way to omit these.
An alternative is to maintain "proper" Depends for the foo-dev package.
("proper" is in quotes, because it is only needed to satisfy pkg-config
wishes).
*sigh*.
/mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 09:41, Michael Tokarev wrote: .. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. And iirc, it was an upstream bug, the dependency should have been listed as non-private-something in the .pc file. /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 00:17, Michael Biebl wrote: .. Patching the upstream provided .pc file in Debian feels odd, tbh. Are you sure Requires.private is only relevant for static linking? Isn't this what Libs.private is for. Yes it feels odd indeed. The problem here is often due to lack of understanding how the .pc files work, which parts should go where. Myself I don't know either how it should be done. I asked about this several times in different places but each time the answers were different. So I ended up working in case-by-case basis: when a .pc file gets new Libs.private or Requires.private, I evaluate how this new library is actually being used, - and in all cases so far it was entirely internal thing not exposed in any way to the users of the said library, *unless* we want static linking (where regular debian shlib mechanism does not work, obviously). Here's just one example of this in one of my packages: https://salsa.debian.org/qemu-team/spice/-/blob/master/debian/rules#L31 (this one comes from #803926) Neither includes nor dynamic libs are needed to build stuff with libsamba-server, the only case where it's needed is when we try to build something statically, so that all libraries used by (non-existing by now) libspice-server.a are needed during link time. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. 18.10.2022 05:27, Adrian Bunk wrote: > The same command with all packages installed outputs: > > $ pkg-config --cflags virglrenderer > -I/usr/include/virgl -I/usr/include/libdrm > $ > > This would be required if headers under /usr/include/libdrm were > included by /usr/include/virgl/virglrenderer.h, but that isn't > the case. Exactly. And this is the case in many other situations too (eg my spice example above). In this very case, all extra dependencies are config-time stuff internal to virglrenderer, it does not change abi/api of its users. It is just that virglrenderer will be able (or not) to use extra features when asked. Even the header files with available options aren't being generated at build time, - it will return ENOSYS-like error at runtime when asked for an optional feature which is not compiled in. The interface of the library does not change in any way. I just don't know how it *should* be done. Maybe pkgconfig should not insist on something.private when asked for cflags? Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
On Mon, Oct 17, 2022 at 10:13:47PM +0300, Michael Tokarev wrote: > 16.10.2022 08:04, Adrian Bunk wrote: > ... > > With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: > > https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1%3A7.1%2Bdfsg-2%2Bb1&stamp=1665894634&raw=0 > > > > The complete list is currently: > > $ pkg-config --cflags virglrenderer > > Package epoxy was not found in the pkg-config search path. > > Perhaps you should add the directory containing `epoxy.pc' > > to the PKG_CONFIG_PATH environment variable > > Package 'epoxy', required by 'virglrenderer', not found > > Package 'libdrm', required by 'virglrenderer', not found > > Package 'gbm', required by 'virglrenderer', not found > > Package 'vulkan', required by 'virglrenderer', not found > > Package 'libva', required by 'virglrenderer', not found > > Package 'libva-drm', required by 'virglrenderer', not found > > $ > > > > In practice, most/all of the -dev build dependencies also have to become > > dependencies of libvirglrenderer-dev. > > Actually this is an interesting question and a quite common issue. > > This package does not provide a static library. > All the mentioned packages are listed in Requires.private pkgconfig tag: > > Version: 0.10.3 > Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, > vulkan, libva, libva-drm > > The thing is: these are needed by a static-link library (dynamic .so > libs are already handled by debian package dependencies). They're not > used when building other software with libvirglrenderer. It is only > pkg-config which fails to find them, for actual usage these are not > needed. > > I used to remove Requires.private: tags from the .pc files in such > cases, entirely, because it makes no sense in this context. And it > makes build just a bit faster too. > > But indeed, many maintainers tend to add lots'a stuff to Depends. > > I'd remove the Requires.private here as well. > > What do you guys think? The same command with all packages installed outputs: $ pkg-config --cflags virglrenderer -I/usr/include/virgl -I/usr/include/libdrm $ This would be required if headers under /usr/include/libdrm were included by /usr/include/virgl/virglrenderer.h, but that isn't the case. > /mjt cu Adrian
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
On Mon, 17 Oct 2022 22:13:47 +0300 Michael Tokarev wrote: 16.10.2022 08:04, Adrian Bunk wrote: ... > With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: > https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1%3A7.1%2Bdfsg-2%2Bb1&stamp=1665894634&raw=0 > > The complete list is currently: > $ pkg-config --cflags virglrenderer > Package epoxy was not found in the pkg-config search path. > Perhaps you should add the directory containing `epoxy.pc' > to the PKG_CONFIG_PATH environment variable > Package 'epoxy', required by 'virglrenderer', not found > Package 'libdrm', required by 'virglrenderer', not found > Package 'gbm', required by 'virglrenderer', not found > Package 'vulkan', required by 'virglrenderer', not found > Package 'libva', required by 'virglrenderer', not found > Package 'libva-drm', required by 'virglrenderer', not found > $ > > In practice, most/all of the -dev build dependencies also have to become > dependencies of libvirglrenderer-dev. Actually this is an interesting question and a quite common issue. This package does not provide a static library. All the mentioned packages are listed in Requires.private pkgconfig tag: Version: 0.10.3 Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, vulkan, libva, libva-drm The thing is: these are needed by a static-link library (dynamic .so libs are already handled by debian package dependencies). They're not used when building other software with libvirglrenderer. It is only pkg-config which fails to find them, for actual usage these are not needed. I used to remove Requires.private: tags from the .pc files in such cases, entirely, because it makes no sense in this context. And it makes build just a bit faster too. But indeed, many maintainers tend to add lots'a stuff to Depends. I'd remove the Requires.private here as well. Patching the upstream provided .pc file in Debian feels odd, tbh. Are you sure Requires.private is only relevant for static linking? Isn't this what Libs.private is for. Looping in Tollef and Andrew, as maintainers of pkgconf/pkg-config. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
16.10.2022 08:04, Adrian Bunk wrote: ... With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1%3A7.1%2Bdfsg-2%2Bb1&stamp=1665894634&raw=0 The complete list is currently: $ pkg-config --cflags virglrenderer Package epoxy was not found in the pkg-config search path. Perhaps you should add the directory containing `epoxy.pc' to the PKG_CONFIG_PATH environment variable Package 'epoxy', required by 'virglrenderer', not found Package 'libdrm', required by 'virglrenderer', not found Package 'gbm', required by 'virglrenderer', not found Package 'vulkan', required by 'virglrenderer', not found Package 'libva', required by 'virglrenderer', not found Package 'libva-drm', required by 'virglrenderer', not found $ In practice, most/all of the -dev build dependencies also have to become dependencies of libvirglrenderer-dev. Actually this is an interesting question and a quite common issue. This package does not provide a static library. All the mentioned packages are listed in Requires.private pkgconfig tag: Version: 0.10.3 Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, vulkan, libva, libva-drm The thing is: these are needed by a static-link library (dynamic .so libs are already handled by debian package dependencies). They're not used when building other software with libvirglrenderer. It is only pkg-config which fails to find them, for actual usage these are not needed. I used to remove Requires.private: tags from the .pc files in such cases, entirely, because it makes no sense in this context. And it makes build just a bit faster too. But indeed, many maintainers tend to add lots'a stuff to Depends. I'd remove the Requires.private here as well. What do you guys think? /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
Control: severity -1 serious Control: retitle -1 libvirglrenderer-dev must depend on packages required for its pkg-config file Control: affects -1 src:qemu Control: tags -1 ftbfs On Sat, Sep 10, 2022 at 02:36:12PM +0300, Michael Tokarev wrote: > Package: libvirglrenderer-dev > Version: 0.10.1-1 > Severity: important > > When a package uses libvirglrenderer-dev, it expects the package to be > self-contained, so the build-dependency is specified against only the > package which is actually used, not about its inter-dependencies. > However, the installed libvirglrenderer-dev isn't useable as it is: > > meson.build:717:2: ERROR: Could not generate cargs for virglrenderer: > Package libva was not found in the pkg-config search path. > Perhaps you should add the directory containing `libva.pc' > to the PKG_CONFIG_PATH environment variable > Package 'libva', required by 'virglrenderer', not found > > This is because virglrenderer.pc refers to libva.pc which is not pulled > in by the dependencies of libvirglrenderer-dev package. > > libva-dev should be added to the Depends: field of libvirglrenderer-dev. > Or maybe debian should have a mechanism to track deps of pkgconfig > files somehow, in a way similar to shared libraries. > > Severity is important because this causes other packages to FTBFS. > Maybe it shuold be serious instead. Changing it to serious. With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1%3A7.1%2Bdfsg-2%2Bb1&stamp=1665894634&raw=0 The complete list is currently: $ pkg-config --cflags virglrenderer Package epoxy was not found in the pkg-config search path. Perhaps you should add the directory containing `epoxy.pc' to the PKG_CONFIG_PATH environment variable Package 'epoxy', required by 'virglrenderer', not found Package 'libdrm', required by 'virglrenderer', not found Package 'gbm', required by 'virglrenderer', not found Package 'vulkan', required by 'virglrenderer', not found Package 'libva', required by 'virglrenderer', not found Package 'libva-drm', required by 'virglrenderer', not found $ In practice, most/all of the -dev build dependencies also have to become dependencies of libvirglrenderer-dev. > Thanks, > > /mjt cu Adrian
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
Package: libvirglrenderer-dev Version: 0.10.1-1 Severity: important When a package uses libvirglrenderer-dev, it expects the package to be self-contained, so the build-dependency is specified against only the package which is actually used, not about its inter-dependencies. However, the installed libvirglrenderer-dev isn't useable as it is: meson.build:717:2: ERROR: Could not generate cargs for virglrenderer: Package libva was not found in the pkg-config search path. Perhaps you should add the directory containing `libva.pc' to the PKG_CONFIG_PATH environment variable Package 'libva', required by 'virglrenderer', not found This is because virglrenderer.pc refers to libva.pc which is not pulled in by the dependencies of libvirglrenderer-dev package. libva-dev should be added to the Depends: field of libvirglrenderer-dev. Or maybe debian should have a mechanism to track deps of pkgconfig files somehow, in a way similar to shared libraries. Severity is important because this causes other packages to FTBFS. Maybe it shuold be serious instead. Thanks, /mjt
