I didn't notice this until today when my list of updates includes both x11-terms/alacritty-0.12.0::gentoo AND x11-drivers/nvidia-drivers-525.105.17:0/525::gentoo. alacritty clearly depends upon the accelerated video driver, and should be updated **after** it. But portage wants to update alacritty **first**, because it doesn't know that alacritty depends on x11-drivers/nvidia-drivers. I presume that part of the problem here is that alacritty can be built against any of several different accelerated video drivers. I don't know what's the best fix here. USE flags for the possible accelerated video drivers perhaps? Or is it better to make it DEPEND upon "any of [...]"? For today I'm just working around it by manually updating x11-drivers/nvidia-drivers first.
I don’t think order matters as alacritty should not link to those libraries. I do not have nvidia system though, so idk how it behaves there. Can you paste output of lddtree /usr/bin/alacritty From an nvidia system? Also it probably can work on llvmpipe without real driver. Opengl virtual is deprecated afaik, it should use glvnd, but I need to verify it.
(In reply to Georgy Yakovlev from comment #1) > I don’t think order matters as alacritty should not link to those libraries. > I do not have nvidia system though, so idk how it behaves there. > Can you paste output of > > lddtree /usr/bin/alacritty > > From an nvidia system? > > Also it probably can work on llvmpipe without real driver. > Opengl virtual is deprecated afaik, it should use glvnd, but I need to > verify it. babylon5:alaric:~:1 $ lddtree /usr/bin/alacritty alacritty => /usr/bin/alacritty (interpreter => /lib64/ld-linux-x86-64.so.2) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 libz.so.1 => /lib64/libz.so.1 libbz2.so.1 => /lib64/libbz2.so.1 libpng16.so.16 => /usr/lib64/libpng16.so.16 libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 libexpat.so.1 => /usr/lib64/libexpat.so.1 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/12/libgcc_s.so.1 libm.so.6 => /lib64/libm.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libc.so.6 => /lib64/libc.so.6 The behavior I have seen is that if I update x11-drivers/nvidia-drivers, and then try to start an alacritty BEFORE rebooting the system to load the newly-updated nVidia driver, then alacritty fails to start, complaining that the nVidia driver version does not match. So there seems to be *some* kind of interdependency there. I suppose it's possible that it may not be a compile-time dependency.
It may be that I'm worrying over nothing, and just overthought it when for the first time ever since I've been using them, both packages updated on the same day.
this error comes from nvidia lib itself, not alacritty. unfortunately that's known issue with nvidia-drivers where kernel and userspace HAS to match. it also makes it impossible to load older kernel with older nvidia on updated userspace and get to desktop, at least I hit it multiple times when I had nvidia card long ago. nothing we can do here, no kind of dep can solve it. the only way is to reboot with kernel nvidia part matching installed lib AFAIK. https://github.com/alacritty/alacritty/issues/4887 if you have dual-gpu hybrid laptop with integrated GPU like intel - you can actually make alacritty always use integrated one via glvnd. https://github.com/alacritty/alacritty/issues/6366 - start here for pointers. if you have a desktop with integrated gpu not connected or without one - well, don't buy nvidia next time =) good luck.
