[arch-general] PKGBUILD "provides" not handled correctly?
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
On Tue, May 1, 2012 at 12:08, Norbert Zeh <nzeh@cs.dal.ca> wrote:
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.
You need to provide a specific version of linux-lts, I believe. An unversioned provides won't match a versioned dependency. Try provides=(linux-lts=3.0.29) ~Celti
On Tue, May 01, 2012 at 04:08:04PM -0300, Norbert Zeh wrote: <snip>
linux-lts-local. I've added "linux-lts" to the conflicts/provides/replaces
also, from man pkgbuild: * replaces (array) "Sysupgrade is currently the only pacman operation that utilizes this field. A normal sync or upgrade will not use its value." So, since aur packages usually find their way through -U into a user's system, this is unnecessary. cheers! mar77i
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")
Thanks for all your quick replies. Immediately after firing off this email, I thought it would be something like this, but for some reason I didn't bother to read the manpage :( Some would have considered this reason enough for a RTFM response. It's wonderful to see that these types of responses are very rare in the arch community. Again, thanks for your help. Cheers, Norbert Jan Steffens [2012.05.01 2134 +0200]:
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")
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Tue, May 01, 2012 at 05:01:16PM -0300, Norbert Zeh wrote:
Thanks for all your quick replies. Immediately after firing off this email, I thought it would be something like this, but for some reason I didn't bother to read the manpage :( Some would have considered this reason enough for a RTFM response. It's wonderful to see that these types of responses are very rare in the arch community. Again, thanks for your help.
RTFM responses aren't rare in arch community. You were just lucky :P But, people admitting that they should have RTFM, as you did, are rare :)
On Wed, 2012-05-02 at 08:30 +0530, gt wrote:
On Tue, May 01, 2012 at 05:01:16PM -0300, Norbert Zeh wrote:
Thanks for all your quick replies. Immediately after firing off this email, I thought it would be something like this, but for some reason I didn't bother to read the manpage :( Some would have considered this reason enough for a RTFM response. It's wonderful to see that these types of responses are very rare in the arch community. Again, thanks for your help.
RTFM responses aren't rare in arch community. You were just lucky :P
But, people admitting that they should have RTFM, as you did, are rare :)
Not sorry for that noise: Some Linux users are humans, not everybody is an alien Linux nerd. RTFM responses usually are longer than concrete answers would be. That RTFM approach is a shame for the Linux community. Anyway, I confess that Arch Wikis are amazing good, easy to read and understand. Smart people ask stupid question, only idiots don't ask, but fake knowledge. Reading manuals does not give the solace that often is needed. Humans tend to be ambivalent. Those who don't wrangle with ambivalent usually are evil. Take a look at the Facebook mob, if they could, they would lynch innocents. :p Ralf
participants (6)
-
gt
-
Jan Steffens
-
Martti Kühne
-
Norbert Zeh
-
Patrick Burroughs
-
Ralf Mardorf