Package: libgl1-mesa-glx Version: 17.2.0~rc6-1 Severity: important The libgl1-mesa-glx transitional package that exists after the libglvnd transition is Architecture: all, but this is not appropriate when a foreign-architecture package like Steam might depend on it. On an amd64 system:
* steam:i386 Depends libgl1-mesa-glx (interpreted as :i386) * Desired result: installing steam:i386 pulls libgl1-mesa-glx:i386 * Actual result: libgl1-mesa-glx (Arch: all) is considered to be part of the primary architecture amd64 and cannot satisfy steam's dependency, because it is not Multi-Arch: foreign It would not be a correct solution to mark libgl1-mesa-glx:all as M-A: foreign, because if it was, this dependency chain would be considered to be valid: steam:i386 -> libgl1-mesa-glx:all -> libgl1:amd64 -> libglx0:amd64 -> libglx-mesa0:amd64 and that is clearly not useful, because the i386 binaries in Steam cannot load an amd64 libGL. The "i386ness" needs to be propagated all the way through the dependency chain. I think libgl1-mesa-glx needs to go back to being Architecture: any. In general, transitional packages for shared libraries and other architecture-dependent bits should themselves be architecture-dependent - the wasted space on mirrors for having a copy of the same content per architecture is small, because transitional packages are small. libgl1-mesa-glx should perhaps also get a Depends on libglx-mesa0? At the moment there is no guarantee that a system with the transitional libgl1-mesa-glx will actually have Mesa's libglx - if the proprietary drivers follow what Mesa has done, then the dependency chain could equally well be satisfied by libgl1-mesa-glx -> libgl1 -> libglx0 -> libglx-nvidia0 which seems rather unexpected! It would seem more reasonable for installing libgl1-mesa-glx to pull in a complete Mesa stack equivalent to what used to be in libgl1-mesa-glx. All the same reasoning probably applies to libegl1-mesa, although I don't really know how EGL works. Regards, S