Mmmh, gtk3 no longer builds after rebasing to staging..

There's quite a few packages that depend on mesa because require libgbm. This is still a bit of a problem because mesa.dev still depends on the mesa drivers. Maybe it would be good to extract libgbm to a separate derivation, or make extra outputs for gbm and gbmdev.

EDIT: this has been fixed in the meantime. mesa.dev no longer depends on mesa.drivers.

Result of nixpkgs-review pr 118479 at d0a5ac03 run on x86_64-linux 1

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement.

I've now also added a commit that breaks the dependency of mesa.dev on mesa.drivers. Packages that use libxatracker now need to depend on mesa.driversdev. (AFAICT this library is almost unused.)

@vcunat what's your opinion on this?

There's quite a few packages that depend on mesa because require libgbm. This is still a bit of a problem because mesa.dev still depends on the mesa drivers. Maybe it would be good to extract libgbm to a separate derivation, or make extra outputs for gbm and gbmdev.

I was wondering about that too. Two additional Mesa outputs certainly have a cost in terms of complexity but then again a separate libgbm package would be nice. But in any case we should avoid adding that to this PR as things are already complicated enough (a dedicated issue(/PR) would IMO be nice though).

the libGL and mesa commits should also have a description that explains the rationale, impact, etc.

Ok, I'll add a rationale to the commit messages.

Depending on how long this takes to review we could also merge (some of) the other commits independently or split them into a separate PR.

I don't think there is any subset of this PR that can be reviewed more easily. Both the mesa and libglvnd changes affect every package that depends on opengl. The other commits just fix the resulting issues.

this part is difficult to review as we don't know which packages this might break (without running a full nixpkgs-review).

I'm happy for suggestions on how to better test this PR. Rebuilding almost all of nixpkgs locally is probably not feasible.

but if mesa.dev provides additional (or even just slightly different headers, e.g. due to older versions - wich seems very likely) this could potentially cause a lot of breakages (and due to the version change alone).

I would not expect any issues here. If you use the nonfree nvidia drivers, you also compile against different headers (i.e., compile against mesa and link against nvidia). That seems to work well.

Also note that we link applications against libglvnd, not mesa. Even if the mesa headers provided more functions, applications couldn't use them because they don't exist in the libglvnd library.

A dedicated output (driversdev) for just xatracker.pc seems a bit strange to me.

This was the easiest way to untangle the dependencies. The xatracker.pc file is the only one that contains references to both the dev output (because of the headers), and to the drivers output (because of the llvm dependency).

Would you prefer to move the xa_*.h and d3dadapter/* headers to the driversdev output as well?

First, defaulting to generic headers instead of mesa's was on my wishlist long ago already, so I do like that – at least in principle, but the risks didn't seem high at a glance. One advantage is that after that mesa will become relatively cheap to update normally (directly in nixpkgs master). E.g. on top of your current PR a mesa update does:

$ ./maintainers/scripts/rebuild-amount.sh HEAD
Estimating rebuild amount by counting changed Hydra jobs.
   1386 x86_64-darwin
    725 x86_64-linux

I'm happy for suggestions on how to better test this PR. Rebuilding almost all of nixpkgs locally is probably not feasible.

We can have a Hydra jobset for this branch. I can set it up myself when you think it's a good moment. I hope most issues would be visible as build failures.

This was the easiest way to untangle the dependencies. The xatracker.pc file is the only one that contains references to both the dev output (because of the headers), and to the drivers output (because of the llvm dependency).

I still feel like missing something here. Why do the packages retain (transitive) dependency to .drivers in case they don't need libxatracker? If a package keeps runtime reference to foo.dev, I'd typically consider it a mistake, though in some cases it may be hard to fix (/cc #118410).

If a package keeps runtime reference to foo.dev, I'd typically consider it a mistake, though in some cases it may be hard to fix (/cc #118410).

It's indeed a mistake, albeit a regular one: see #98755 for another recent case. You also need to dev output to compile C programs that use mesa as a dependency. It's nice if you don't have to download (unused) mesa drivers and a (second) copy of LLVM for that.

I can set it up myself when you think it's a good moment.

I'm not sure if we should also move the headers to the driversdev output (instead of just the pkg-config file). Aside from that, I'd say this is PR is ready.

@vcunat I've rebased the PR to staging and moved the corresponding headers to the driversdev output as well. I think it would be a good time for the hydra jobset now.

I hope it won't hit many issues that are regressions in master..staging; if so, we'd better "change base" for the purpose of testing. Here's the jobset: https://hydra.nixos.org/eval/1661526

I've fixed all the new failures (compared to master) that seem to be mesa-related.