You are not logged in.
Can anyone think of any ill effects of adding the following to kernel26-ck's PKGBUILD:
provides=("kernel26-ck-headers=${pkgver}" "kernel26-headers=${pkgver}")Why? In my case, I don't run with the kernel26 at all, but I do use virtualbox which depends on the kernel26-headers package. Thanks for the advice.
Offline
If you want a provides= line, you'll need a conflicts= line as well I guess.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
@B - that's kind of the point. Is it kosher to two packages provide the same thing? In other word, kernel26-headers and kernel26-ck-headers both providing "kernel26-headers"? Can this cause problems?
Offline
I'd suggest (in that case) that both packages must provide files in the same locations as well. This wouldn't actually affect anything except any pre-compiled kernel modules (which you shouldn't be using if you're removing kernel26 anyway).
And yes, two packages can provide the same thing. Check out nvidia-utils-beta vs nvidia-utils, both provide basically the same files.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
@ng - thanks for the reply. The other case is someone having both kernel26 and kernel26-ck on their system.
Offline
Can anyone think of any ill effects of adding the following to kernel26-ck's PKGBUILD:
provides=("kernel26-ck-headers=${pkgver}" "kernel26-headers=${pkgver}")
provides=("kernel26-headers=${pkgver}") will be enough to do the trick.
the effects? well, an example will be: if you want to install virtualbox there's no need to install kernel26-headers from [core] 'cause kernel26-ck-headers provides the modules needed for re/compiling the vbox modules too.
Arch64/DWM || My Dropbox referral link
Offline
fyi virtualbox does not depend on kernel26-headers - it makedepends on it. I use the stock virtualbox package with my custom kernel without any additional provides=, conflicts=, etc.
Offline
package_virtualbox() {
pkgdesc="Powerful x86 virtualization for enterprise as well as home use"
depends=('libxml2' 'libxcursor' 'libidl2' 'libxinerama' 'sdl' 'libxmu' 'curl' 'libvncserver' 'libpng' 'kernel26-headers' 'gcc' 'make')
...
}one of us must be wrong.
Arch64/DWM || My Dropbox referral link
Offline
I'd suggest (in that case) that both packages must provide files in the same locations as well.
That's not possible, in this case
.
Just check the contents of any kernel26*-headers package. Even if you'd start hacking around to move things, that would still make no sense at all. Most configuration/make files pick up the running kernel unless you specify otherwise, and that automatism will break.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
So consensus is that having the following in my PKGBUILD is fine...?
provides=("kernel26-ck-headers=${pkgver}" "kernel26-headers=${pkgver}")1) Folks without the ARCH kernel can benefit from packages that depends on the headers
2) This won't hurt folks with both kernels
Lemme know if I'm wrong about this.
Offline
Apologies for the above, had an Irish moment. ![]()
However the fact remains that I don't need to make any of the changes suggested above to my custom kernel's PKGBUILD to facilitate virtualbox, so I'm not sure why you do.
Offline
Actually, I think you should just fix the virtualbox (make) dependencies, and not use a provides= line. Your headers package will mislead other packages that might need the official headers, so whlie what ngoonee said is technically not desirable or possible, he still makes a good point.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline