Created attachment 218777 [details] [patch] don't build & install extra files to stage/ check-plist fails for graphics/libosmesa. This may have started happening with the switch to meson. ================ ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: include/GL/gl.h Error: Orphaned: include/GL/glcorearb.h Error: Orphaned: include/GL/glext.h Error: Orphaned: include/KHR/khrplatform.h Error: Orphaned: lib/libglapi.so Error: Orphaned: lib/libglapi.so.0 Error: Orphaned: lib/libglapi.so.0.0.0 ===> Checking for items in pkg-plist which are not in STAGEDIR ===> Error: Plist issues found. *** Error code 1 ================ The attached patch addresses this by not building / installing files that libosmesa does not need or use.
I can't reproduce this. I've built libosmesa several times since the meson update, and the package cluster is also fine. Do you have any special options of any kind? In any case, I'd want input from manu as well before making changes.
(In reply to Niclas Zeising from comment #1) As far as I can see, the package cluster doesn't run the check-plist target? I think that poudriere bulk -t or testport will run that. The following log shows that it is not running check-plist (nor stage-qa). http://beefy9.nyi.freebsd.org/data/114amd64-default/552369/logs/libosmesa-20.2.0_1.log I am not running with anything particularly special. My poudriere etc/poudriere.d/<jail>/make.conf: DEVELOPER=yes DEFAULT_VERSIONS+=ssl=openssl LANG=en_US.UTF-8 DEVELOPER=yes is ignored by poudriere, so that should be a no-op (see comment above about using bulk -t or testport). The others shouldn't make a difference for this either, but I have not yet tried a test without them.
Build and package info is available at https://gitlab.com/swills/freebsd-ports/pipelines/209959803
Comment on attachment 218777 [details] [patch] don't build & install extra files to stage/ (In reply to Niclas Zeising from comment #1) Adding manu@ as Niclas Zeising suggested.
There are other ports that include some of those files, like for example: $ git grep lib/libglapi.so graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so.0 graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so.0.0.0 graphics/mesa-libs/pkg-plist:lib/libglapi.so graphics/mesa-libs/pkg-plist:lib/libglapi.so.0 graphics/mesa-libs/pkg-plist:lib/libglapi.so.0.0.0 So including them in plist would be problematic. On the other hand, libOSMesa library is linked against those files, so you can't remove, at least, some of them. # ldd ../stage/usr/local/lib/libOSMesa.so ../stage/usr/local/lib/libOSMesa.so: libglapi.so.0 => /usr/local/lib/libglapi.so.0 (0x8012d0000) libz.so.3 => /lib/libz.so.3 (0x801507000) libstdc++.so.9 => /usr/lib/gcc80/libstdc++.so.9 (0x80151d000) libm.so.4 => /lib/libm.so.4 (0x8016a0000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x8016cc000) libc.so.8 => /lib/libc.so.8 (0x800462000)
I forgot to mention this is in DPorts but it's probably the same in freebsd-ports since (excerpt from meson.build): if with_opengl install_headers( 'GL/gl.h', 'GL/glcorearb.h', 'GL/glext.h', subdir : 'GL', ) endif
I'm able to reproduce this locally: [00:02:06] Error: Orphaned: include/GL/gl.h [00:02:06] Error: Orphaned: include/GL/glcorearb.h [00:02:06] Error: Orphaned: include/GL/glext.h [00:02:06] Error: Orphaned: include/KHR/khrplatform.h [00:02:06] Error: Orphaned: lib/libglapi.so [00:02:06] Error: Orphaned: lib/libglapi.so.0 [00:02:06] Error: Orphaned: lib/libglapi.so.0.0.0 and the patch does fix it.
Indeed it does, since it removes the opengl stuff from the build/install list. The point is, why was it enabled in the first place? Is it really needed for some port to work properly?
(In reply to Antonio Huete Jimenez from comment #5) Yes, indeed libOSMesa.so links with libglapi.so. And graphics/libosmesa correctly depends on graphics/mesa-libs. In comment 5, you seem concerned that libglapi.so (or other files) could be removed, thus breaking graphics/libosmesa. That won't happen because of the documented dependency. (In reply to Antonio Huete Jimenez from comment #8) You ask why was it (-Dopengl) enabled. When it was committed (ports r552109), there was no explanation why it was enabled (nor in the review for that commit). Maybe manu@ or zeising@ can weigh in. But as far as I can tell (on reading the meson build files and actually building / installing), it does not need to be enabled for the libosmesa build. As you pointed it, having 'opengl' enabled triggers an install of gl.h and some other header files. Those are already installed by graphics/mesa-libs, so graphics/libosmesa does not need to enable the installation of those files itself. Additionally, it triggers the build and install of libglapi.so - as described, mesa-libs already makes libglapi.so available. In my review, libglapi as built by the graphics/mesa-libs port is correct and sufficient for the needs of libosmesa. It is not built any differently by mesa-libs than it is if -Dopengl=enabled is set for libosmesa build. In fact, if it WERE built differently in a material way, then when libosmesa linked with mesa-lib's version of libglapi.so at run-time, that would be a problem. So it is best that graphics/libosmesa links against the version of libglapi.so from graphics/mesa-libs rather than try to build one itself.
check-plist doesn't complain now, closing.
(In reply to Emmanuel Vadot from comment #10) If you apply the patch (using -Dopengl=false), then you don't need the @comment hacks in pkg-plist, and it cuts build time (although not that much).