[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#874013: libgl1-mesa-glx: transitional library package should not be Arch: all



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


Reply to: