on a : -mesa USE=-libglvnd (constrained for... historical reasons)... -keeping kde-frameworks/* to KFMIN=5.82.0 && having USE=-wayland everywhere with the exception of mesa and xorg-server, Upgrading plasma-meta from 5.21.5 to 5.22.5 will fail because of : - kwayland-server (dependency pushed by plasma-meta and kwin) - kinfocenter for the same reason of a conflict between libglvnd and mesa USE=-libglvnd It appears that reverting (R)DEPEND = ...libglvnd... of these packages to their 5.21.5 counterparts, v.g : - media-libs/mesa[egl] (kwayland-server) - media-libs/mesa[X(+)] (kinfocenter) enables everything to build and run perfectly fine. After a quick look at the code, I have not spotted any potential problem and therefore would consider this change to bring a (minor) enhancement for user convenience. BTW, no hardfeeling if this bug is closed WONTFIX for potentially infringing Gentoo dev policy / practice or whatever I know nothing about, this report will at least stay to help those in such a case. Reproducible: Always
(In reply to Eric F. GARIOUD from comment #0) > on a : > > -mesa USE=-libglvnd (constrained for... historical reasons)... > -keeping kde-frameworks/* to KFMIN=5.82.0 && having USE=-wayland everywhere > with the exception of mesa and xorg-server, > > Upgrading plasma-meta from 5.21.5 to 5.22.5 will fail because of : > > - kwayland-server (dependency pushed by plasma-meta and kwin) > - kinfocenter > > for the same reason of a conflict between libglvnd and mesa USE=-libglvnd > Will let others comment on the rest. > It appears that reverting (R)DEPEND = ...libglvnd... of these packages to > their 5.21.5 counterparts, v.g : > > - media-libs/mesa[egl] (kwayland-server) > - media-libs/mesa[X(+)] (kinfocenter) > > enables everything to build and run perfectly fine. > The problem is that Mesa will be dropping USE=egl, I believe, when a new version comes out soon which moves legacy drivers into a separate component AFAIK. > After a quick look at the code, I have not spotted any potential problem and > therefore would consider this change to bring a (minor) enhancement for user > convenience. > > BTW, no hardfeeling if this bug is closed WONTFIX for potentially infringing > Gentoo dev policy / practice or whatever I know nothing about, this report > will at least stay to help those in such a case. Thank you for being polite, it is appreciated (genuinely). We often have people getting rather angry if something happens they disagree with. I'm not an expert on this so wil leave to others.
(In reply to Sam James from comment #1) > (In reply to Eric F. GARIOUD from comment #0) > > BTW, no hardfeeling if this bug is closed WONTFIX for potentially infringing > > Gentoo dev policy / practice or whatever I know nothing about, this report > > will at least stay to help those in such a case. > > Thank you for being polite, it is appreciated (genuinely). We often have > people getting rather > angry if something happens they disagree with. I'm not an expert on this so > wil leave to others. Just going to leave this here: https://bugs.gentoo.org/728290#c6
Depending on mesa rarely make sense if anything unless need a mesa-specific feature, it'd be a bit like depending on nvidia-drivers directly. libglvnd provides both headers and the libraries to link with, and non-glvnd is not supported anymore. wrt comment #2 link, if you need nvidia-drivers:0/340 then I'd suggest to look into the ::nvidia-legacy overlay[1] rather than the ::noglvnd one (or other workarounds) which plays a lot better with gentoo's current layout. If that's not enough, then I suggest to look into other workarounds than try to get gentoo's ebuilds changed not to use libglvnd. [1] https://gitlab.com/shibotto/nvidia-legacy
I wouldn't mind changing dependencies to virtual/opengl (which nvidia-drivers:340 users could potentially override), but I'm not going to do it myself.
It is unclear what enhancement the bug reporter is trying to propose. Let's just look at the dependencies here: > $ lddtree /usr/lib64/libKWaylandServer.so > libKWaylandServer.so => /usr/lib64/libKWaylandServer.so (interpreter => none) > libEGL.so.1 => /usr/lib64/libEGL.so.1 > libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 > libdl.so.2 => /lib64/libdl.so.2 > $ lddtree /usr/lib64/qt5/plugins/kcm_opengl.so > kcm_opengl.so => /usr/lib64/qt5/plugins/kcm_opengl.so (interpreter => none) > libEGL.so.1 => /usr/lib64/libEGL.so.1 > libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 > libGLX.so.0 => /usr/lib64/libGLX.so.0 > libOpenGL.so.0 => /usr/lib64/libOpenGL.so.0 What package(s) do these belong to? > $ equery b libEGL.so.1 libGLX.so.0 libOpenGL.so.0 > * Searching for libEGL.so.1,libGLX.so.0,libOpenGL.so.0 ... > media-libs/libglvnd-1.3.4 (/usr/lib/libEGL.so.1 -> libEGL.so.1.1.0) > media-libs/libglvnd-1.3.4 (/usr/lib64/libEGL.so.1 -> libEGL.so.1.1.0) > media-libs/libglvnd-1.3.4 (/usr/lib/libOpenGL.so.0 -> libOpenGL.so.0.0.0) > media-libs/libglvnd-1.3.4 (/usr/lib/libGLX.so.0 -> libGLX.so.0.0.0) > media-libs/libglvnd-1.3.4 (/usr/lib64/libOpenGL.so.0 -> libOpenGL.so.0.0.0) > media-libs/libglvnd-1.3.4 (/usr/lib64/libGLX.so.0 -> libGLX.so.0.0.0) At that point I could essentially say: Case closed. Let me instead introduce you to a portage feature called package.provided: https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided If you think you have a package installed that provides these files instead of libglvnd, feel free to add it to this portage mechanism in order to rely on your out-of-tree solution.
(In reply to Sam James from comment #1) A/ Thank you Sam for the job you achieve for Gentoo and for the way you achieve it. B/ For what is about dropping egl in future versions of mesa, I did not know that but, never mind, I blocked > mesa-20.0.8-r1 ;-) ----------- (In reply to Ionen Wolkens from comment #2) I make no doubt that your suggestion (moving to nvidia-legacy) is the best way to follow for all those who expect experimenting the latest kernel versions or have comfortable life expectations for their systems… and… themselves. I am not one of these. :-) ----------- (In reply to Andreas Sturmlechner from comment #5) The way you suggest (package.provided) is indeed a working solution hic&nunc. I had followed this path with mesa a long time ago until xorg-server began needing particular headers from the mesa package. The drawback of such a solution is that it acts transparently (I mean irrespective of the changes on the package being stated as provided) and system-wide. Then unless you follow the evolution of that package as well as the evolution of the packages that depend on it, you might well wake-up some morning under a broken system and some huge work to understand why and implement a workaround. To this respect, I find less risky to act locally on 2 packages (4 if we need to add KF85's plasma & kwayland) which life expectancy won't exceed 4 months anyway. Thank you (all above mentioned devs) for your helpful contributions. I acknowledge my solution as being a quick and dirty fix compared to Ionen's suggestion. And therefore, as written in the OP, feel free to flag this bug WONTFIX.
(In reply to Matt Turner from comment #2) Pfff! You do not even know that such a "contribution" should belong to ComRel!
