XPost: linux.debian.bugs.dist

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Control: reopen -1
Control: found -1 17.2.0-1

On Fri, 01 Sep 2017 at 23:08:26 +0100, Simon McVittie wrote:

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.

Thanks for making libgl1-mesa-glx version 17.2.0-1 Architecture: any.
However, it is also Multi-Arch: foreign. As I explained in the quoted text, M-A: foreign is not appropriate in this case, and will break
cross-architecture packages like steam and wine. It should be M-A: same.

Regards,
smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On 06.09.2017 13:11, Simon McVittie wrote:

Control: reopen -1
Control: found -1 17.2.0-1

On Fri, 01 Sep 2017 at 23:08:26 +0100, Simon McVittie wrote:

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.

Thanks for making libgl1-mesa-glx version 17.2.0-1 Architecture: any. However, it is also Multi-Arch: foreign. As I explained in the quoted text, M-A: foreign is not appropriate in this case, and will break cross-architecture packages like steam and wine. It should be M-A: same.

Your original text let me believe that making it arch:any would be
enough to fix this issue.

Fixed in git.

--
t

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)