There won’t be more problems. If he only wanted to remove the driver completely (without updating) he won’t have to uninstall more, since, when my proposal is used, linuxXX-nvidia would be there instead of linuxXX-430. So it won’t get worse, but stay the same.
On the other side, since he wanted to uninstall it to install a newer driver afterwards, my proposal would even solve this issue.
Because if he would use a mhwd config just called “nvidia” without a version number in it, he wouldn’t need to remove an older driver first and switch mhwd profiles for updating. MHWD wouldn’t have to do anything in this case, which would just vanish the problem with updating the nvidia driver while linux-lts or linux-latest metapackages are installed.
I’m not talking about removing the older nvidia driver versions here. This could be a topic for another thread, since for very old hardware, the open source driver may be better anyway, but like I said, this is not the topic of this thread.
The older nvidia driver version would stay in the repos, so anyone who needs them could just continue using them.
A meta package which installs this old legacy drivers wouldn’t be useful because they don’t get updates anymore. So it would be a package pointing to another fixed package forever. This doesn’t help anyone.
So I think a metapackage (and mhwd profile) just for the very latest nvidia driver would be enough.
Have you every had problems with the newest nvidia driver? I nevery had. Until now it was always the opposite, that the older drivers were causing problems because of incompatibilities with newer software.
In very most cases there shouldn’t be a need (and want) to use an older nvidia driver.
But yeah, a simple mhwd profile and metapackage wouldn’t remove the older drivers, so the option to use them would still be there, if you want to.
Better notifications could help a little. But not much.
Casual users are used to just click away any popups / notifications. Many won’t know that they need to manually update there driver, even if there was a notification.
This is also part of why there is a linux-latest metapackage now, which gets automatically installed if a someone uses an EOL kernel.
This would not fix the problem of having to do the updating of the driver manually. See my main post:
Manjaro is a semi-rolling distribution because it has periodic sets of updates so it makes sense that drivers and kernels are also not rolling so they do not break when used in the sets of updates. I think the only way to get a true rolling package is to use a true rolling distribution.
I want to be able to automatically update the nvidia driver, without having to uninstall packages and install new ones.
The package should stay the same, only the driver version contained should update. This way there are no package operations needed.
This would have the pros of:
Not needing to uninstall everything depending on nvidia
Not having to download a newer build of the older driver branch before switching to the new driver branch
My best idea for a solution is to have one “video-nvidia” mhwd profile, which uses one package per kernel (“linuxXX-nvidia”) which stays always installed and gets updated always to the newest driver.
This way we won’t have to uninstall stuff and reinstall it after. The installed package list will stay the same, only the version of the one package itself changes.
So just like it was in the old days, when there were not all the different nvidia driver versions in the repo but just one at a time (and per supported gpus).
Currently we have packages like linux59-nvidia-450xx linux59-nvidia-455xx
Now there would be an additional mhwd profile and package: linux59-nvidia // (or maybe linux59-nvidia-latest)
This package would contain currently driver version 455.
But when for example driver 460 comes out, this exact package (linux59-nvidia) would become driver 460. Without changing its name. Without having to uninstall an old package and install a new one. It would stay the same, but contain the newer driver.
This would be optimal.
It can. We already have proven it in the past, when Manjaro used this exact approach.
Also Arch does the same and some other distros. So it is definitely possible.
Yeah, fine. They can continue to do so. There would be only an additional mhwd profile + package. I’m not talking about removing the existing one. So no harm is done here.
Yes, this is already the case for all the different driver versions and mhwd profiles which are currently in the repo. Adding one more shouldn’t be a problem.
Users using the mhwd profile for latest nvidia driver would get updated from 440 to 450 series.
This will keep their systems fully functional, since using older driver versions often break things because they are not compatible in combination with all the other new packages (cuda, ffmpeg nvenc, others using nvidia apis…)
Well, people can ask here in the forum. But I doubt this will happen often. Nvidia driver are usually well tested in my experience.
At least people have usually more problems when staying on older version compared to the latest anyway.
But in case they do have problems, they can just stay on the older version, as this new profile I suggest is only an addition to the existing ones.
Ok understand… what you are looking for is then exclude mhwd and use a meta package like arch. Using a config “latest-yx” is not really useful in mhwd. That means extra packages that need to be managed and therefore extra work.
Anyway… the packages are already there. The script i mention above do what you expect, but it doesn’t overwrite it, but rather remove the old ones and install the new ones. I see no real benefit of your idea now… only a preference.
I still prefer the mhwd profile over a metapackage or pacman hook.
The downsides of just a metapackage:
There is no mhwd support. Updating the kernel means having to manually uninstall the metapackage for the driver first, update kernel with mhwd, afterwards installing the metapackage manually again for the new kernel. This are the manual steps I wan’t to avoid.
The downsides of the pacman hook:
On system update, it will first install the newest version of the old (currently installed) nvidia driver branch before downloading and installing the newer driver branch.
This means we have to download unnecessary packages which will get uninstalled soon after installation again.
If you have a fast internet connection this may be fine. But as in some locations in Germany here, I would really like to avoid any unnecessary downloads.
It needs to uninstall the old driver version first (before installing the new one), which is not possible if you have packages installed depending on nvidia (for example cuda and nvtop).
So we have to manually uninstall and remember those packages to be able to update the driver, then afterwards manually install these packages again.
These manual steps is what I try to avoid and the reason why I started this forum thread.
What I want is a fully automatic driver update. Without manual steps or unnecessary downloads.
You may say these manual steps are easy.
Well to that I can say yes, maybe for me. I know how to handle metapackages and update the driver. Maybe only noobs won’t.
But since I have to do this on multiple machines it is really annoying. So it should be fully automatic.
The goal here is that only running normal system updates is enough to keep nvidia driver up to date.
No unnecessary downloads, no manual package uninstalls/installs.
As far as I know, this is currently only possible with an additional (rolling) mhwd profile.
just my first thoughts… guess this won’t be possible because you have to do system updates first to update mhwd for the new profile of the new driver to be even available to install. So detecting new nvidia drivers before system update is not possible.
Second thing is:
Will this be installable in an easy way for everyone? How do you tell noobs on how to install pacman hooks?
Also, how will they be updated, in case somthing in the logic changes?
I would still prefer an official, obvious way. Like another mhwd profile for a rolling driver.
Especially since I’m not the only one struggling with this.
See threads / quotes like this:
Now the maintainer needs to fill this everytime with the latest driver… but this wont be updated to next version… it will stuck on 455… now create a meta package with the 455xx driver with a name video-nvidia-latest.
If you need this i can create a AUR package at least… xD
PS: The conflicts needs an update… at least some meta packages must be added in my opinion.
Yes this is a really good solution. Thank you a lot!
Of course, it could be uploaded as an AUR package.
this will conflict with the different Manjaro branches. When do you update the package? You would have to maintain 4 different packages for this, keeping each timely in sync with the current repo states.
it may be no good solution for noobs. Not everyone know how to (and wants to) enable the AUR
It will not be able to automatically update from a root script with just pacman, since aur builders need a non-root user and usually interaction and a quick look at the PKGBUILD
So because of this reasons, I think it would be a great idea to include this in the official repos! @philm what do you think?
Funny reactions to that answer He just says, that he personally wouldn’t implement the config and I myself don’t need that. I am happy with mhwd and how it works now. But that doesn’t mean that someone else could contribute one:
Soo don’t be lazy and create a nice a patch, if you really think that it is worth the time @Bleuzen@squart
not every user wishing for a feature automatically has the knowledge and skills to implement it. Guess it would be much easier for those who already worked with and created mhwd.
even if a user would make a patch, it is not a single time contribution. Someone would have to maintain it alongside the driver. Besides that, we not even have write access to some place where to maintain.
someone would have to build, sign and upload it to the repos. Normal users are not able to do this.
the answer didn’t sound very interested, so it would not be worth it, if the patch would be just ignored anyway.
So we first need someone from the Manjaro team who is interested in this. If there are only users, we can’t do much about it alone.