Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Nvidia packages are not the same version (Read 287 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Nvidia packages are not the same version

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

Re: Nvidia packages are not the same version

Reply #1
Apologies. I've updated it to lib32-nvidia-utils.

It'll take a while for the mirrors to sync, as usual.
the runit guy on artix

Re: Nvidia packages are not the same version

Reply #2
It appears the issue has crept up once again. I've updated my post with the current versions I have installed.

Re: Nvidia packages are not the same version

Reply #3
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.

Re: Nvidia packages are not the same version

Reply #4
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
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:
Code: [Select]
#! /usr/bin/bash

VER="1.2.3"
DEP="somepkg"
depvar="('$DEP-$VER')"
echo "$depvar"

Re: Nvidia packages are not the same version

Reply #5
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.

 

Re: Nvidia packages are not the same version

Reply #6
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:
Code: [Select]
# 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