Public bug reported:

[Impact]
Any applications which link against libglapi.so.0.0.0 are unable to declare a 
dependency on the only package which provides libglapi.so.0.0.0 in Resolute 
(libglapi-amber), due to libglapi-amber's conflict with libglapi-mesa. One such 
example is nsight-systems' GUI binary: 
https://bugs.launchpad.net/ubuntu/+source/nsight-systems-13-1/+bug/2150165

Attempting to install libglapi-amber forces the uninstallation of
libglapi-mesa, which cascades into the removal of the modern
Wayland/GNOME graphics stack and the ubuntu-desktop metapackage.

These Conflicts, Breaks, Replaces in debian/control have been present
since the mesa-amber branch was originally forked to prevent file and
ABI collisions. However, I have been analyzing whether this conflict is
still necessary, and have not found any evidence that this package
clashes with anything in-distro, so the conflict might now be obsolete
due to upstream Mesa refactoring.

Resolute's stock Mesa no longer provides the standalone
/usr/lib/x86_64-linux-gnu/libglapi.so.0 library, and libglapi-amber is
now the exclusive provider of this file path on the system.

Modern Mesa upstream also seems to have comprehensively prefixed its internal 
dispatch symbols (e.g., _mesa_glapi_tls_Dispatch, _mesa_glapi_add_dispatch). 
The Amber legacy branch continues to use the un-namespaced symbols 
(_glapi_tls_Dispatch, _glapi_add_dispatch). I performed the following 
experiment to try and determine if these symbols are defined anywhere else in 
the distro, and did not find any such instances:
1. Aggregate all defined symbols from `nm -D --defined-only libglapi.so.0.0.0`
2. Search https://codesearch.debian.net/ for each symbol
3. For each source package found in (2), download all binary packages
produced by that source package in Ubuntu 26.04
4. Run `nm -D --defined-only <ELF file>` for each ELF file in each
binary package
5. Flag any other packages/files that export any of the same symbols in (1)

I reached out to upstream to get their opinion on this, and have not
received a reply (https://lists.freedesktop.org/archives/mesa-
dev/2026-June/226657.html)

Because there is no evident overlap in the file paths and strict
separation in the dynamic linker namespaces, I've found no evidence to
suggest modern Gallium drivers and legacy Amber DRI drivers can't safely
coexist in the same process address space without RTLD_GLOBAL linker
collisions or ABI merging.

Dropping Conflicts: libglapi-mesa, Breaks: libglapi-mesa, and Replaces:
libglapi-mesa tags from the libglapi-amber package would then enable
applications which link against libglapi.so.0.0.0 to declare a
dependency on libglapi-amber.

[Test Plan]

Provision a fresh Ubuntu Resolute (26.04) system with ubuntu-desktop
installed.

Attempt to install the amber package:
sudo apt install libglapi-amber

[Actual behavior]
Notice that apt calculates a massive package removal, specifically targeting 
libglapi-mesa and ubuntu-desktop. Abort the installation.

[Expected behavior]
Verify that the package installs cleanly. Ensure 
/usr/lib/x86_64-linux-gnu/libglapi.so.0 is written to disk alongside existing 
modern Mesa files, and that ubuntu-desktop is completely unaffected.

Reboot and confirm the GNOME/Wayland desktop session starts normally
using the modern Mesa drivers.

[Regression Potential]
The regression potential is very unclear to me. Given that I only had *Debian* 
code search at my disposal for my experiment, I can't confidently say that the 
symbols it found were 100% aligned with the Resolute archive state - and if I 
did miss an overlapping symbol in some package X, it's possible that things 
could break in package X if it is coinstalled with libglapi-amber.

apt-file confirms that no other package in the Resolute archive claims
ownership of libglapi.so.0.0.0, so we at least know there is no risk of
dpkg overwriting modern Mesa files in the primary archives.

AFAICT from the detailed experiment, modern desktop environments
(Mutter/Wayland) and GLVND use modern Gallium drivers, which are hard-
linked against the _mesa_glapi_* namespace, so they should be blind to
the legacy un-namespaced symbols provided by the Amber library.

The legacy libglapi.so.0 library should simply sit dormant on the disk
unless an older client or application dynamically loads it.

[Other Info]
Running nm -D against modern Mesa components vs Amber indicates that the Mesa 
components reference only the namespaced symbols:

Modern: nm -D /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 | grep glapi
shows U _mesa_glapi*.

Amber: nm -D /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 | grep glapi
shows T _glapi_*.

** Affects: mesa-amber (Ubuntu)
     Importance: Low
         Status: New

** Affects: mesa-amber (Ubuntu Resolute)
     Importance: Low
         Status: New

** Affects: mesa-amber (Ubuntu Stonking)
     Importance: Low
         Status: New

** Changed in: mesa-amber (Ubuntu)
   Importance: Undecided => Low

** Also affects: mesa-amber (Ubuntu Resolute)
   Importance: Undecided
       Status: New

** Also affects: mesa-amber (Ubuntu Stonking)
   Importance: Low
       Status: New

** Changed in: mesa-amber (Ubuntu Resolute)
   Importance: Undecided => Low

** Description changed:

  [Impact]
- Any applications which link against libglapi.so.0.0.0 are unable to declare a 
dependency on the only package which provides libglapi.so.0.0.0 in Resolute 
(libglapi-amber), due to libglapi-amber's conflict with libglapi-mesa.
+ Any applications which link against libglapi.so.0.0.0 are unable to declare a 
dependency on the only package which provides libglapi.so.0.0.0 in Resolute 
(libglapi-amber), due to libglapi-amber's conflict with libglapi-mesa. One such 
example is nsight-systems' GUI binary: 
https://bugs.launchpad.net/ubuntu/+source/nsight-systems-13-1/+bug/2150165
  
  Attempting to install libglapi-amber forces the uninstallation of
  libglapi-mesa, which cascades into the removal of the modern
  Wayland/GNOME graphics stack and the ubuntu-desktop metapackage.
  
  These Conflicts, Breaks, Replaces in debian/control have been present
  since the mesa-amber branch was originally forked to prevent file and
  ABI collisions. However, I have been analyzing whether this conflict is
  still necessary, and have not found any evidence that this package
  clashes with anything in-distro, so the conflict might now be obsolete
  due to upstream Mesa refactoring.
  
  Resolute's stock Mesa no longer provides the standalone
  /usr/lib/x86_64-linux-gnu/libglapi.so.0 library, and libglapi-amber is
  now the exclusive provider of this file path on the system.
  
  Modern Mesa upstream also seems to have comprehensively prefixed its internal 
dispatch symbols (e.g., _mesa_glapi_tls_Dispatch, _mesa_glapi_add_dispatch). 
The Amber legacy branch continues to use the un-namespaced symbols 
(_glapi_tls_Dispatch, _glapi_add_dispatch). I performed the following 
experiment to try and determine if these symbols are defined anywhere else in 
the distro, and did not find any such instances:
  1. Aggregate all defined symbols from `nm -D --defined-only libglapi.so.0.0.0`
  2. Search https://codesearch.debian.net/ for each symbol
  3. For each source package found in (2), download all binary packages
  produced by that source package in Ubuntu 26.04
  4. Run `nm -D --defined-only <ELF file>` for each ELF file in each
  binary package
  5. Flag any other packages/files that export any of the same symbols in (1)
  
  I reached out to upstream to get their opinion on this, and have not
  received a reply (https://lists.freedesktop.org/archives/mesa-
  dev/2026-June/226657.html)
  
  Because there is no evident overlap in the file paths and strict
  separation in the dynamic linker namespaces, I've found no evidence to
  suggest modern Gallium drivers and legacy Amber DRI drivers can't safely
  coexist in the same process address space without RTLD_GLOBAL linker
  collisions or ABI merging.
  
  Dropping Conflicts: libglapi-mesa, Breaks: libglapi-mesa, and Replaces:
  libglapi-mesa tags from the libglapi-amber package would then enable
  applications which link against libglapi.so.0.0.0 to declare a
  dependency on libglapi-amber.
  
  [Test Plan]
  
  Provision a fresh Ubuntu Resolute (26.04) system with ubuntu-desktop
  installed.
  
  Attempt to install the amber package:
  sudo apt install libglapi-amber
  
  [Actual behavior]
  Notice that apt calculates a massive package removal, specifically targeting 
libglapi-mesa and ubuntu-desktop. Abort the installation.
  
  [Expected behavior]
  Verify that the package installs cleanly. Ensure 
/usr/lib/x86_64-linux-gnu/libglapi.so.0 is written to disk alongside existing 
modern Mesa files, and that ubuntu-desktop is completely unaffected.
  
  Reboot and confirm the GNOME/Wayland desktop session starts normally
  using the modern Mesa drivers.
  
  [Regression Potential]
  The regression potential is very unclear to me. Given that I only had 
*Debian* code search at my disposal for my experiment, I can't confidently say 
that the symbols it found were 100% aligned with the Resolute archive state - 
and if I did miss an overlapping symbol in some package X, it's possible that 
things could break in package X if it is coinstalled with libglapi-amber.
  
  apt-file confirms that no other package in the Resolute archive claims
  ownership of libglapi.so.0.0.0, so we at least know there is no risk of
  dpkg overwriting modern Mesa files in the primary archives.
  
  AFAICT from the detailed experiment, modern desktop environments
  (Mutter/Wayland) and GLVND use modern Gallium drivers, which are hard-
  linked against the _mesa_glapi_* namespace, so they should be blind to
  the legacy un-namespaced symbols provided by the Amber library.
  
  The legacy libglapi.so.0 library should simply sit dormant on the disk
  unless an older client or application dynamically loads it.
  
  [Other Info]
  Running nm -D against modern Mesa components vs Amber indicates that the Mesa 
components reference only the namespaced symbols:
  
  Modern: nm -D /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 | grep glapi
  shows U _mesa_glapi*.
  
  Amber: nm -D /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 | grep glapi
  shows T _glapi_*.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2156409

Title:
  libglapi-amber still conflicts with standard graphics stack, but
  unclear if this is still necessary

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa-amber/+bug/2156409/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to