On Tue, May 1, 2012 at 9:08 PM, Norbert Zeh <nzeh@cs.dal.ca> wrote:
Hi folks,
I have just run into a weird problem. I have a machine that isn't too happy with the 3.3.x kernel series. So I'm running linux-lts on it, but that one is meant for servers, so isn't as responsive as one would like on a desktop system. So I've decided to throw a little PKGBUILD together that compiles linux-lts with CONFIG_HZ set to 1000 but is otherwise unchanged from the version in ABS.
To ensure this tweaked lts kernel does not get inadvertently overwritten by a linux-lts upgrade, I've changed the package name in the PKGBUILD to linux-lts-local. I've added "linux-lts" to the conflicts/provides/replaces lists in the PKGBUILD to ensure that I do not install linux-lts and linux-lts-local at the same time and to ensure that all packages that rely on linux-lts continue to have their dependencies satisfied...or so I thought.
Compiling the tweaked lts kernel and installing this kernel instead of linux-lts on my laptop with intel graphics works without problems. My office desktop is a machine with an NVIDIA card and I'm using nvidia-lts as my graphics driver. When trying to replace linux-lts with linux-lts-local using pacman -U, pacman complains that nvidia-lts requires linux-lts>=3.0.0 and refuses to continue. Now I'm confused: linux-lts-local provides linux-lts, and the version is 3.0.29-1. So why does pacman complain? Any pointers are much appreciated.
Cheers, Norbert
If you don't specify a version to provide, the provides will be unversioned and fail any version comparisons. So: provides=("linux-lts=$pkgver-$pkgrel")