Arch Linux

My preference goes for the 1st choice:
* mesa-dri package with all dri drivers (except swrast)
* mesa-vdpau package with vdpau drivers
* mesa package with omx and swrast, i don't want a mesa package that depends on dri drivers.
* opencl-mesa package with pipe modules

btw, thanks for your work Emil :)

Thanks for picking my suggestion :)

Is there any technical issues with picking swrast within mesa-dri and getting mesa to depend on mesa-dri or it's more of a personal preference ?

It's a packaging preference:
Mesa package is needed for proprietary drivers for building gl apps (gl headers), adding a dependency for mesa with mesa-dri is not the best choice.
So in that case it's better to have swrast driver in mesa package instead of mesa-dri.

I believe you meat to say "mesa package is required (makedep) by gl apps, even when the proprietary drivers are installed" - that's definitely the case.

Still don't see how that affects the mesa<>mesa-dri relationship - are you concerned over the extra package being pulled while building those apps ?
I assume that the primary objective is to get things to work(tm) rather than easing the (automated?) build process.

We can't have mesa depends on mesa-dri because mesa-dri depends on mesa-libgl, which will break nvidia/catalyst drivers.

Speaking of interdependencies noticed that you've added libgl as a dep to mesa. So let me untangle the whole thing, and please point out if I've got any of it wrong.

opencl-mesa
* should not depend on mesa-libgl - does not link against it, nor it makes sense. It will break for people using nvidia-libgl/nvidia-opencl, who want to try opencl-mesa on their radeon GPU. As mesa-libgl goes away we need libxcb for the auth with X. The latter is not needed if one enables rendernodes (default to on with ~3.15 iirc).

mesa-vdpau
* it's a vdpau-backend(make sure it provides it), and does not need or have any relation to mesa, mesa-libgl or mesa-dri. Module requires libdrm, libxcb and expat.

mesa-dri
* should not depend on mesa or mesa-libgl (ideally we'll add expat to the deps). Why - those are lib{E,}GL "backends". How about sanity checks - see below
Virtually no-one but mesa (with it's lib{E,}GL) + xf86-video-* needs these. Why not pull this package from mesa-libgl, see the nvidia-304xx-libgl note below.

mesa
* Provides "custom" lib{E,}GL and libGLESv* libgbm and osmesa. Only a few packages should need this - ex. kmscon (libgbm) wine(osmesa) nvidia-304xx-libgl(old blob is missing libEGL and libGLES, use mesa's)

mesa-libgl
* Very rare for any packages to explicitly need this and not libgl - bumblebee(BB) is the only example.

Sanity checks:
* Install anything that needs "libgl" (i.e. lib{E,}GL), pacman prompts you between mesa-libgl, nvidia-{304xx-,}libgl, which pulls mesa and mesa-dri.
* Install BB - the rest of mesa is installed everything works like a charm.
* Install programs that do not need libgl, but other mesa libraries (libgbm) - mesa + mesa-dri are installed.
* Install ati-dri and then want to run libgl game... the game has already pulled in the whole (rest?) of mesa - mesa-libgl, mesa.

The attached files resolve the mesa & mesa-dri1 base packages. The rest of "odd packages depending one mesa" is being reported gradually.

Update: The ddx depend on mesa-dri.

With the above work one will flatten out the dependency trees, as currently they are quite circular.

Sorry for the long reply, it seems like saying half and hinting about the rest was not enough :\

Cheers
-Emil

What about these dependencies?

Checking mesa-vdpau-10.3.0-2-x86_64.pkg.tar.xz
mesa-vdpau E: Dependency libx11 detected and not included (libraries ['usr/lib/libX11-xcb.so.1', 'usr/lib/libX11.so.6'] needed in files ['usr/lib/vdpau/libvdpau_nouveau.so.1.0.0'])
mesa-vdpau E: Dependency llvm-libs detected and not included (libraries ['usr/lib/libLLVM-3.5.so'] needed in files ['usr/lib/vdpau/libvdpau_nouveau.so.1.0.0'])
Checking opencl-mesa-10.3.0-2-x86_64.pkg.tar.xz
opencl-mesa E: Dependency elfutils detected and not included (libraries ['usr/lib/libelf.so.1'] needed in files ['usr/lib/gallium-pipe/pipe_r600.so', 'usr/lib/gallium-pipe/pipe_radeonsi.so'])
opencl-mesa E: Dependency expat detected and not included (libraries ['usr/lib/libexpat.so.1'] needed in files ['usr/lib/libMesaOpenCL.so.1.0.0'])
opencl-mesa E: Dependency libdrm detected and not included (libraries ['usr/lib/libdrm.so.2', 'usr/lib/libdrm_radeon.so.1'] needed in files ['usr/lib/libMesaOpenCL.so.1.0.0', 'usr/lib/gallium-pipe/pipe_r600.so', 'usr/lib/gallium-pipe/pipe_radeonsi.so'])
opencl-mesa E: Dependency libxext detected and not included (libraries ['usr/lib/libXext.so.6'] needed in files ['usr/lib/libMesaOpenCL.so.1.0.0'])
opencl-mesa E: Dependency libxfixes detected and not included (libraries ['usr/lib/libXfixes.so.3'] needed in files ['usr/lib/libMesaOpenCL.so.1.0.0'])

Caught me red-handed - nouveau guy here, so llvm and opencl are not the things I normally build.
So I take it that, apart from the missing dependencies, my analysis makes sense ?

yes, currently fixing mesa package. Nvidia guys seem happy with your changes too :p

Great. Now all we need is some packages to transition from "mesa" to "libgl", and package maintainers to add the extra libgl (for linking purposed) when building GL apps.
I've already opened a few bugreports for the former, but the latter may (?) warrant a message to all devs. Otherwise there may be a mass panic as to why things fail to link.

Thanks for keeping up with my nagging :)

Got a small issue in the -2 version:

/usr/share/licenses/mesa-dri/LICENSE exists in both 'lib32-mesa-dri' and 'mesa-dri'
/usr/share/licenses/mesa/LICENSE exists in both 'mesa' and 'lib32-mesa'

me too:

error: failed to commit transaction (conflicting files)
/usr/share/licenses/mesa/LICENSE exists in both 'mesa' and 'lib32-mesa'
Errors occurred, no packages were upgraded.