Many packages do not declare correctly a dependency on gl

[kwryankrattiger]

Steps to reproduce

Using this environment

# This is a Spack Environment file.
#
# It describes a set of packages to be installed, along with
# configuration settings.
spack:
  # add package specs to the `specs` list
  specs:
  - vtk
  view: true
  concretizer:
    unify: true
  packages:
    vtk:
      require: ['@9.2.6', +osmesa~mpi]

Then follow the normal concretization steps for the enviornment

spack env activate vedge_test_env
spack concretize

Error message

The gl providers osmesa and glx are both present in the DAG. VTK is built to support osmesa, but the glew is using the glx version of gl which is not compatible.

For some reason, spack seems to be ignoring the osmesa provided gl completely.

Information on your system

• Spack: 0.23.0.dev0 (7f3dd38)
• Python: 3.8.10
• Platform: linux-ubuntu20.04-skylake
• Concretizer: clingo

General information

• I have run spack debug report and reported the version of Spack/Python/Platform
• I have searched the issues of this repo and believe this is not a duplicate
• I have run the failing commands in debug mode and reported the output

[kwryankrattiger]

CC: @alalazo @scottwittenburg

[alalazo]

The bug is not in the concretizer, but in vtk which says:

depends_on("osmesa", when="+osmesa")

This brings in osmesa without considering the node a gl provider.

[alalazo]

Changed the title, since handling of virtual packages from the concretizer works fine.

[alalazo]

The entire OpenGL ecosystem is modeled in a very complex way, and I think it can be simplified a lot. For instance, we have a virtual libosmesa, introduced in #19528, that is not really needed. I'll start removing that.

[alalazo]

A few issues I saw so far in the graphics stack:

1. mesa has conditionals in its recipe for variants that don't exist (e.g. egl)
2. mesa has an opengl boolean variant, that cannot be turned off (so it is useless, and just adds complexity)
3. Many packages are both depending on the virtual (e.g. gl) and adding direct dependency to implementations. This will not work with our software model.