mesa has a huge amount of dependants

[Atemu]

Issue description

Mesa is depended upon by thousands of packages necessitating staging for every bump. Mesa is a package that gets upstream releases pretty much every staging-next cycle and many users depend on fixes they bring.

From what I can tell, packages usually depend on mesa for:

• libgbm
• libdrm (propagated through mesa)
• dri
• gles (headers?)
• other gl stuff

Sample of packages from my closure that depend on it:

• wine
• lutris (via libretro)
• mpv (gbm)
• appimage
• libva
• libvdpau
• qemu
• virglrenderer
• SDL2
• firefox
• egl-wayland
• webkitgtk
• wlroots (libdrm and libgbm)
• xdg-desktop-portal-wlr
• steam FHSenv
• xorgserver/xwayland
• mesa-demos

All chromiums require gbm apparently:

• spotify
• atom
• chromium
• discord
• signal
• libcef
• electron

The first simple step to fixing this is to figure out which packages actually only need libdrm which gets propagated but not actually provided by mesa. These can simply switch to using libdrm directly.

I believe we can replace many if not all instances of gl/gles stuff dependence with libglvnd.

dri is pretty much only depended on by xorgservers which I guess is fine. It's really just those two packages I believe and they're rather small leaf packages.

The big one is libgbm. As long as chromium needs it, tonnes of packages (that have rather lengthy build times I might add) will depend on it.
Is it possible to decouple libgbm from mesa somehow?

[K900]

We can definitely build libgbm separately from the rest of Mesa.

[Atemu]

How separate are we talking? Thing is that it needs to be independent of updating our regular mesa or we'd be left with the same issue.

Another idea I've had would be to do something like

{
  mesa_22_3_5 = callPackage ../development/libraries/mesa/22.3.5.nix { ... };
  mesa_22_3_6 = callPackage ../development/libraries/mesa/22.3.6.nix { ... };
  mesa_22 = mesa_22_3_6;
  mesa_23_0_0 = callPackage ../development/libraries/mesa/23.0.0.nix { ... };
  mesa_23 = mesa_23_0_0;
  mesa = mesa_22;
  libgbm = mesa_22_3_5;
}

and then only do libgbm bumps on staging.

[K900]

That's basically what I was thinking, yes. Maybe we can just build libgbm as its own package, but that doesn't seem to be well supported upstream right now.

[FRidh]

libgbm = mesa_22_3_5;

That's basically what I was thinking, yes. Maybe we can just build libgbm as its own package, but that doesn't seem to be well supported upstream right now.

If building separately is difficult, would it be an option to create "virtual" top-level packages that symlink the libs/headers/...? That way it becomes more clear when which package is needed, as it will simply fail.

[K900]

We can just move libgbm to its own output.

[vcunat]

That won't help with the OP, i.e. we still won't be able to merge mesa bumps directly to master.

[K900]

It won't, but we will be able to have multiple Mesa versions more confidently.

[Atemu]

What actually solves the original issue is the decoupled structure I mentioned. Moving libgbm to its own output makes it harder to inadvertently depend on mesa directly. It's not exclusive, it's in addition and we likely want both.

I'd say something like this would be a good goal:

{
  mesa_22_3_5 = callPackage ../development/libraries/mesa/22.3.5.nix { ... };
  mesa_22_3_6 = callPackage ../development/libraries/mesa/22.3.6.nix { ... };
  mesa_22 = mesa_22_3_6;
  mesa_23_0_0 = callPackage ../development/libraries/mesa/23.0.0.nix { ... };
  mesa_23 = mesa_23_0_0;
  mesa = mesa_22;
  libgbm = mesa_22_3_5.libgbm;
}

I'd begin with the decoupling started in https://github.com/NixOS/nixpkgs/pull/217883 and then refactor libgbm dependants to use "libgbm" which is an output of mesa like above afterwards.

[K900]

I don't think we should have more than one Mesa release per series, tbh. This will get out of hand really quickly. I'd rather have latest, latest-amber and whatever libgbm uses.

[vcunat]

I certainly don't see use for each patch version.

[Atemu]

The reason I list patch versions is that we bump i.e. 22.3.5 -> 22.3.6 quite regularly but wouldn't want to upgrade libgbm to 22.3.6 at the same time.

I agree that we shouldn't keep a lot of them but they don't really hurt either IMO. I think keeping the current + previous/next 1 or 2 would be a good policy IMO.

[Atemu]

WIP at https://github.com/NixOS/nixpkgs/pull/219534