You are not logged in.
Hi,
I maintain a kernel driver which uses dkms and requires the kernel headers during build. What is the policy about makedepends? Should I simply add linux-headers? I had a look at other packages and could see things like:
makedepends=('linux-headers>=4.13' 'linux-headers<4.14')
Can someone explain this to me? Why restricting the kernel version? Are there instances 'linux-headers' (without versioning) is acceptable?
Thanks a lot in advance.
Offline
Are there instances 'linux-headers' (without versioning) is acceptable?
Yes, and yes. If you are making a dkms package, look at other dkms packages as examples - they should all have unversioned linux-headers as make-depends: that's the whole point of dkms.
Non-dkms kernel modules will have versioned kernel dependencies.
You can specify a range (the >= or <, etc) if the package your making needs something that has either been recently added or may be on it's way out. But generally this isn't particularly relevant in a rolling release like arch: if your package doesn't work with currentish kernels then there are other problems.
Last edited by Trilby (2017-09-14 12:23:33)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
zebulon wrote:Are there instances 'linux-headers' (without versioning) is acceptable?
Yes, and yes. If you are making a dkms package, look at other dkms packages as examples - they should all have unversioned linux-headers as make-depends: that's the whole point of dkms.
Non-dkms kernel headers will have versioned kernel dependencies.
Thanks for your answer. Still, there are many instances where the version is specified, for instance in nvidia-dkms or bbswitch-dkms. Hence my trouble.
Offline
Oops, sorry, I was looking at the depends for those packages.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Oops, sorry, I was looking at the depends for those packages.
That's fine. But do you mean it is better to version headers in makedepends? Or is it okay to leave them unversioned?
Also, I see sometimes linux in the depends. Is it really necessary? I thought that packages of the base and base-devel groups did not need to be specified as depends.
Last edited by zebulon (2017-09-14 15:27:41)
Offline
I'm not familiar with creating dkms packages. But in general it's best to not use versioned dependencies unless you know there is a need for them.
EDIT: packages in base-devel do not need to be listed in depends. This guideline is controversial, but it is the current standard - however there is no such criteria for base group. If your package depends on anything in the base group it must be listed. Of course one would assume that some kernel must be installed - but for a dkms package it is not sufficient to have some kernel, the end user must have the [core]/linux package specifically.
Last edited by Trilby (2017-09-14 15:30:04)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Thank you very much Trilby, this is very clear. Are these recommendations in the documentation? I tried to find guidelines there, but maybe I did not search correctly.
Offline
The current guidelines are in the wiki. It looks like the suggestion that base-devel package need not be listed may only be for makedepends.
In any case, there's no harm in listing anything your package directly relies on. Perhaps I've been wading in the Python pool a bit too much lately, but "explicity is better than implicit".
As for the "controversial" part - I don't have links, but it's been discussed on these forums, on mailing lists, and likely in the wiki talk tabs.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Thanks for pointing me in the right direction.
Offline
The dkms package already optdepends on all headers packages in the official repos, so I don't see any point in duplicating those optdepends.
Furthermore those PKGBUILDs in the repos are split packages which also create the binary, non-dkms versions of the drivers... which is where the makedepends come from. It is completely wrong for dkms packages to makedepends on the headers packages... the dkms package installs a source code archive to /usr/src, and executing
cp -r "$srcdir"/drivername-$pkgver "$pkgdir"/usr/src/
is not functionality which requires kernel headers.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
The dkms package already optdepends on all headers packages in the official repos, so I don't see any point in duplicating those optdepends.
Furthermore those PKGBUILDs in the repos are split packages which also create the binary, non-dkms versions of the drivers... which is where the makedepends come from. It is completely wrong for dkms packages to makedepends on the headers packages... the dkms package installs a source code archive to /usr/src, and executing
cp -r "$srcdir"/drivername-$pkgver "$pkgdir"/usr/src/
is not functionality which requires kernel headers.
I see. Actually, I think that my problem is that I mistakenly build the driver in my PKGBUILD, whereas I should only install it and let this part for dkms. I took over this driver https://aur.archlinux.org/cgit/aur.git/ … u-dkms-git and there is:
build() {
cd "rtl8812au-driver-5.2.9"
make clean
make
}
Should I remove the build section?
Offline
Yes, you should remove it. That build() function is only appropriate for a rtl8812au-git package, and on top of that you don't even install the build module.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Yes, you should remove it. That build() function is only appropriate for a rtl8812au-git package, and on top of that you don't even install the build module.
Thanks. That said, I saw that some split packages work that way, e.g. bbswitch-dkms:
pkgbase=bbswitch
pkgname=(bbswitch bbswitch-dkms)
...
build() {
...
[make]
...
}
package_bbswitch() {
...
[install binary]
...
}
package_bbswitch-dkms() {
...
[install dkms.conf and source to /usr/src]
...
}
Am I correct that here build() is executed only to be installed in package_<binary>(); but that package_<binary>-dkms() is only installing the dkms and source files? But that for a "pure" dkms package, there is no need for buid().
Offline
Correct.
Of course this is basically all only relevant for packages like bbswitch that are in the official repositories since if you are building the binary modules yourself you might as well *just* use dkms. The split package_*() allows you to prebuild them.
I've also seen PKGBUILDs that makedepend on the -dkms package and the relevant kernel headers, then use dkms to build() the relevant kernel module and package() it as a separate package.
Last edited by eschwartz (2017-09-15 15:38:30)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thank you for your time and these explanations.
Offline