multimedia/libva-glx: convert to subpackage

[jbeich]

Summary

Converting X11 and WAYLAND options is left for later: requires more care due to option nesting in consumers.

Test Plan

3 consumers built fine in poudriere.

$ poudriere testport -j 132amd64 multimedia/libva~glx
[...]
=>> Checking shared library dependencies
 0x0000000000000001 NEEDED               Shared library: [libGL.so.1]
 0x0000000000000001 NEEDED               Shared library: [libX11.so.6]
 0x0000000000000001 NEEDED               Shared library: [libc.so.7]
 0x0000000000000001 NEEDED               Shared library: [libdl.so.1]
 0x0000000000000001 NEEDED               Shared library: [libva-x11.so.2]
 0x0000000000000001 NEEDED               Shared library: [libva.so.2]

 $ pkg info -xd glx
 libva-glx-2.20.0_1:
-        libxcb-1.15_1
-        libXfixes-6.0.0
-        libXext-1.3.4,1
-        libX11-1.8.7,1
         libva-2.20.0_1
         libglvnd-1.7.0
-        libdrm-2.4.120,1

Note, libX11 is currently tracked by main (aka libva). After X11 is subpackaged GLX_IMPLIES will be SELF_DEPENDS.glx+=x11.

[jbeich]

• Propagate libGL dependency from GLX option

[arrowd]

multimedia/libva/Makefile

25

Why have the GLX option at all now? Can't it just be removed?

[jbeich]

multimedia/libva/Makefile

25

To avoid libGL dependency at build time. libGL itself depends on libX11, so GLX can probably be merged into X11. However, the complexity of port options controlling subpackages won't disappear: necessary for restricted environments, debugging, transition period and until requires/provides are supported (in ports that have to use flavors instead of subpackages).

[arrowd]

multimedia/libva/Makefile

25

To avoid libGL dependency at build time.

Is this worth pursuing? Subpackages are expected to increase build times in cases such as this one, but binary package users won't see this dependency anymore.

Or does libGL pull in LLVM transitively?

[jbeich]

multimedia/libva/Makefile

25

See bug 261202. Until it's possible to avoid X11 dependencies via binary packages users will build via ports but subpackages may degrade ports support if port options need to be removed. GLX here is a stepping stone to subpackage other options.

libGL doesn't pull LLVM but X11 in DEs may require xorg-server -> mesa-dri -> LLVM.

[arrowd]

multimedia/libva/Makefile

25

subpackages may degrade ports support if port options need to be removed

Sorry, I didn't get that part. Can you please elaborate?

[jbeich]

multimedia/libva/Makefile

25

Mainly when building outside of poudriere e.g., portmaster, local debugging or no root priveleges. Also, building a subset of subpackages within a port may be blocked by licensing framework (e.g., LICENSES_REJECTED=GPLv3).

[arrowd]

multimedia/libva/Makefile

25

portmgr@ is demoting support for building on the host (as a consequence, all the tools that do that - portmaster, synth, etc). We shouldn't bother ourselves with build-on-host scenarios, especially if it gets in the way of simplification.

As for licensing - I don't see how subpackages are different from options in this regard. If user has LICENSES_REJECTED=GPLv3 it will not be able to build a port that optionally depends on GPLv3 port anyways.

[jbeich]

multimedia/libva/Makefile

25

• poudriere requires root but some ports/ committers use the cluster machines (lacks root unless reserved via clusteradm@) to test ports either on non-x86 due to qemu-user-static bugs or due to slow x86 local machine
• users can select options compatible with licensing preferences unlike subpackages that require everything at build time

[jbeich]

Obsolete after 920a3d1486c8 and looked ugly due to limitations:

• Missing USES.<subpkg> and USE_*.<subpkg> helpers to limit abstracted {LIB,RUN}_DEPENDS (avoid bloating main subpackage)
• <opt>_*_DEPENDS.<subpkg> don't seem to work contrary to what D16457 promised

[pizzamig]

Hi. I'm a bit confused by your comments.
If a subpackage is associated to an OPTION, what is the need to duplicate everything with <opt>_*_DEPENDS.subpkg ?
There is no need for subpkg to be there.
subpkg is a way to create multiple packages from the same build, not to configure builds.
Am I missing something?

[jbeich]

• libva (aka main subpackage) must not run-depend on libGL (unlike libOpenGL but it's not used here) and (in future, not part of this review) on X11 libraries in order to be suitable for headless or Wayland-only systems
• <opt>_SUBPACKAGES working but <opt>_SELF_DEPENDS.<subpkg> not working is very confusing

In D43530#993630, @pizzamig wrote:

If a subpackage is associated to an OPTION, what is the need to duplicate everything with <opt>_*_DEPENDS.subpkg ?

Limit runtime dependencies to the specific subpackage the OPTION builds for. Packages and subpackages don't record build dependencies. Subpackages are supposed to not just split installed files but also split runtime dependencies.

If subpackages are to replace (not augment) port options then <opt>_SUBPACKAGES helper should be removed.

[pizzamig]

I understand what you mean.
If I understand correctly what you are trying to do, you define the glx subpkg that is built iff the GLX option is enabled.
A solution could be to not use GLX_LIB_DEPENDS.glx but only LIB_DEPENDS.glx
If the subpackage glx is not built, the dependency should be ignored.

However, options that configure how a subpackage is built are not supported.
This is an area of improvement (and complexity :/ )

[jbeich]

In D43530#993639, @pizzamig wrote:

A solution could be to not use GLX_LIB_DEPENDS.glx but only LIB_DEPENDS.glx

Indeed, if GLX option is disabled then SUBPACKAGES is empty (or lacks glx) and LIB_DEPENDS.glx and SELF_DEPENDS.glx become nop. The style is a bit confusing.

However, options that configure how a subpackage is built are not supported.

I mainly need USES.<subpkg> and USE_*.<subpkg> even in ports that don't have options.

[pizzamig]

It's a valid point.
I guess we need to work on USES/USE_ support heavily.