You are not logged in.
I maintain a few AUR packages and one of them has a dependancy on kernel headers. linux-headers is now a dependancy for this. No problem. Yet I personally use linux-ck quite a bit. It would be nice to define a condition where the depends requirement would be that at least one of the packages in a string would have to be met?
In my example: depends() would be defined as: linux-headers OR linux-ck-headers
Is this possible and simple?
Last edited by wdirksen (2013-07-09 16:33:07)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
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.
Last edited by lolilolicon (2013-07-09 12:36:39)
This silver ladybug at line 28...
Offline
Offline
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.
Offline
Except that this is entirely wrong. linux-ck-headers cannot possibly provide linux-headers.
Of course.
*mentally slaps the imperfect PKGBUILD*
This silver ladybug at line 28...
Offline
OK, I guess no simple oneliner solution here.
I realize now that except for different kernel flavors, that there would probably never be another situation for this
Last edited by wdirksen (2013-07-10 13:51:51)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
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?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
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.
Offline
Thanks, I'm still unsure about this part though:
/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?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Offline
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!
Last edited by wdirksen (2013-07-10 15:52:59)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
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.
Offline
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.
Last edited by wdirksen (2013-07-11 09:19:16)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline