This has occurred several times before, where nvidia, nvidia-utils, and lib32-nvidia-utils are not on the same version. This prevents steam, and possibly other software from starting. Usually, the culprit has been lib32-nvidia-utils. Instead of opening a new thread every time this issue occurs, I'll keep this thread updated. These are the current versions I have:
nvidia 430.26-1
nvidia-utils 430.26-1
lib32-nvidia-utils 430.14-1
Apologies. I've updated it to lib32-nvidia-utils.
It'll take a while for the mirrors to sync, as usual.
It appears the issue has crept up once again. I've updated my post with the current versions I have installed.
Unfortunately, there's no dedicated maintainer for the kernel (and its modules), there's bound to be a delay before all updates roll in.
I personally keep all kernels, nvidia and virtualbox in IgnorePkg and update manually once o month or less. Using suspend-to-disk too with weeks of uptime, so it doesn't make much sense to constantly update them anyway.
Could you use shell expansion in a depends field? depends=('foobar=$pkgver') or something like that? But the required single quotes might stop that.
man PKGBUILD suggests there could be some auto version detection for libraries:
"If the dependency name appears to be a library (ends with .so), makepkg will try to find a binary that depends on the library in the built package and append the version needed by the binary. Appending the version yourself disables automatic detection."
I just happened to be reading that recently and wondered what it meant. But possibly making lib32-nvidia-utils depends=() on some .so if it uses any in the other nvidia things might stop the upgrade mismatch problems.
https://bbs.archlinux.org/viewtopic.php?id=238210 (https://bbs.archlinux.org/viewtopic.php?id=238210)
The link on the end post shows the depends field in the package function being created first and then inserted as a variable, so you might be able to do something like:
#! /usr/bin/bash
VER="1.2.3"
DEP="somepkg"
depvar="('$DEP-$VER')"
echo "$depvar"
That's understandable. The fact I'm not facing any other problems with Artix at the moment is impressive in itself. I have a force of habit to update every other day. Wouldn't adding the kernel and nvidia to ignorepkg be considered partial upgrading? That may cause other issues.
The kernel and its modules are not (versioned) dependencies of other packages, so breaking is very unlikely if you keep them ignored, because there are layers of abstraction between them and applications. Non rolling-release distros do that. Our web and MX servers, running Artix of course, are at over 5 months uptime and going.
Now, unless you've got very new hardware (like the latest Ryzen2) which receives constant kernel updates and you might really benefit in performance and stability, you don't need every single update that gets pushed in the repos. My old Core2 laptop ran on tailored linux-pf-3.14.something and nvidia for many months and countless hibernate/resume cycles, all the rest being updated daily. Same goes for my current laptop, 90 cycles, 42 days of uptime and going strong:
# zgrep Freezing /var/log/everything.* |wc -l
90
# uptime
11:07:11 up 42 days, 15:36, 2 users, load average: 0.31, 0.28, 0.33
# uname -a
Linux hyperion 4.20.14-1-ck-haswell #1 SMP PREEMPT Tue Mar 5 16:47:13 EST 2019 x86_64 GNU/Linux