falconindy wrote:lolilolicon wrote:The problem is solved for you by
provides=("linux-ck-headers=${pkgver}" "linux-headers=${pkgver}")
in the linux-ck-headers PKGBUILD
So you can just put linux-headers to depends=().
I think provides=() is intended to just solve this sort of situation.
Except that this is entirely wrong. linux-ck-headers cannot possibly provide linux-headers.
I always assumed what lollicon said:
➜ ~/ pacman -Si linux-ck-headers ... Provides : linux-ck-headers=3.9.9 linux-headers=3.9.9 <---- ...
The PKGBUILD might require graysky's [repo-ck] to be enabled in /etc/pacman.conf though.
For my educational benefit then, is it so that? . . .
I could setup depends without arguments, "depends()" in this case, because regardless of the type of ArchLinux based kernel, if it is packaged as stated above, the proper header package would natively be "pre-provided"?
I'm gonna uninstall some header packages and give this a go. This is fun.
]]>lolilolicon wrote:The problem is solved for you by
provides=("linux-ck-headers=${pkgver}" "linux-headers=${pkgver}")
in the linux-ck-headers PKGBUILD
So you can just put linux-headers to depends=().
I think provides=() is intended to just solve this sort of situation.
Except that this is entirely wrong. linux-ck-headers cannot possibly provide linux-headers.
I always assumed what lollicon said:
➜ ~/ pacman -Si linux-ck-headers
...
Provides : linux-ck-headers=3.9.9 linux-headers=3.9.9 <----
...
The PKGBUILD might require graysky's [repo-ck] to be enabled in /etc/pacman.conf though.
]]>This may be a silly question - but how does your build mechanism (makefile, etc) know which headers to use?
If the kernel headers aren't actually required for building properly, then you might be able to get away with listing them as opt deps. If they are required for building, how does the build know which set to use if the user has both installed (I do).
I assume there must be some sort of use of `uname` to get the proper path to the kernel headers. Could a similar evaluation be used in the depends array?
The package is this one: https://aur.archlinux.org/packages/open-sasc-ng/
Matching headers to the kernel are definately required to build as there is a virtual loopback DVB adaptor being created by this package. I personally comment out the depends() as I know that the proper headers are already installed and remain updated with the kernel updates. It's not that big of a deal because most users will be using the standard arch-linux kernel. I just thought that the AUR package could be a bit slicker if you could specify for other commonly used archlinux kernels, such as linux-ck.
I like the input here, so thanks!
]]>/lib/modules/$kernver/build is a symlink to the kernel "source" (headers). It's simply the standard convention.
Works fine until you want to build a module for 3.10-foo when you've booted with 3.10-bar.
How is $kernver set/interpreted? Would that also depend on which kernel the user is currently booted into?
]]>This may be a silly question - but how does your build mechanism (makefile, etc) know which headers to use?
If the kernel headers aren't actually required for building properly, then you might be able to get away with listing them as opt deps. If they are required for building, how does the build know which set to use if the user has both installed (I do).
/lib/modules/$kernver/build is a symlink to the kernel "source" (headers). It's simply the standard convention.
I assume there must be some sort of use of `uname` to get the proper path to the kernel headers. Could a similar evaluation be used in the depends array?
Works fine until you want to build a module for 3.10-foo when you've booted with 3.10-bar.
]]>If the kernel headers aren't actually required for building properly, then you might be able to get away with listing them as opt deps. If they are required for building, how does the build know which set to use if the user has both installed (I do).
I assume there must be some sort of use of `uname` to get the proper path to the kernel headers. Could a similar evaluation be used in the depends array?
]]>Except that this is entirely wrong. linux-ck-headers cannot possibly provide linux-headers.
Of course.
*mentally slaps the imperfect PKGBUILD*
The problem is solved for you by
provides=("linux-ck-headers=${pkgver}" "linux-headers=${pkgver}")
in the linux-ck-headers PKGBUILD
So you can just put linux-headers to depends=().
I think provides=() is intended to just solve this sort of situation.
Except that this is entirely wrong. linux-ck-headers cannot possibly provide linux-headers.
]]>provides=("linux-ck-headers=${pkgver}" "linux-headers=${pkgver}")
in the linux-ck-headers PKGBUILD
So you can just put linux-headers to depends=().
I think provides=() is intended to just solve this sort of situation.
]]>In my example: depends() would be defined as: linux-headers OR linux-ck-headers
Is this possible and simple?
]]>