I'm curious what the use-case is.

Dynamic pkgver implies the PKGBUILD becomes unbuildable on frequent occasion, and that it usually tracks the version of the kernel, which should only be the case for in-tree modules.

Ordinarily, I'd say that you shouldn't depend on a versioned makedepends but should instead dynamically detect the version to build against during build() since it seems a lot cleaner.

"August 2015", mhhh, I have to guess, but I think I tried to write a PKGBUILD for 'kdbus-git'. So yeah, out-of-tree kernel-module. But I think the same issue appears whenever you use the version of your package to somehow deduce the minimal version of a dependency.

For instance, imagine a package that turns linux-api-headers into Python stubs. The package would require the same 'makedepends' line as mentioned above (but on 'linux-api-headers' of course). So if you build v4.16.12 of the imaginary 'python-linux-api-stubs', it would require v4.16.12 of 'linux-api-headers', then parse those headers and generate the corresponding python-stubs. You would require an exact version match, otherwise the resulting package would either have outdated data, or would contain future data and thus the package would contain future data.

Sure, using a '>=' dependency is the less problematic part, but it means the built package might be severely different from what other people get when building the package. Especially in the example above, the generated python stubs might be built for the wrong kernel version, and thus contain lots of stuff not available in the version that was targetted.

In case of out-of-tree kernel modules you really need the exact version match, since there is no compatibility guarantee.

I don't mind if this is closed with "WONTFIX". I just wondered whether you are aware of the issue. I can see that out-of-tree modules are not a high priority, especially given that it is easy to work around it here.

No, out-of-tree modules are fine. I just think it would be more intuitive to not care which version it gets built against. This does assume that the source code can target multiple versions, which I *thought* was the case with most out-of-tree modules, since they don't generally use the same version schedule as the kernel, but use #ifdefs to match multiple kernel versions.

So instead, you'd accept any version as a makedepends, but set the depends in package() to whichever version was installed.

This would result in a PKGBUILD that does not require updating hardcoded versions (in pkgver or anywhere else) for every kernel bump -- you'd just bump the pkgrel to get people to rebuild, but it would autodetect its own dependencies.

It seems counter-intuitive for the pkgver to contain the kernel version instead of the module version, if the two are different.

Yeah, I agree in case of actual packages that are built based on tarballs. In those cases you want the package to have its own version and a clear build *and* runtime dependency. However, this gets less clear with VCS-builds, imo.

Lets say you have an out-of-tree module that is stable and gets rarely changed. Lets call it "ootmod". Consider its VCS PKGBUILD 'ootmod-git', which always builds the latest -git version. You want to be able to build this package against any kernel the caller has installed, but you also want the version number to be meaningful. The only solution I see is to somehow incorporate the kernel-version in the package version. The module version itself might not change at all. The module itself might be unmodified, so you need some external version information.

So what would you do here?

The advantage of writing pkgver() that reads the target kernel-version and uses this (possible appended to the version of the module itself), is that the resulting package has a meaningful version that can be compared to a non-VCS package of the module.

For non-VCS packages, you can create one module-package for each kernel you support. Like 'ootmod', 'ootmod-lts', 'ootmod-zen', etc. and then update the package release everytime the kernel is updated. But this requires active updates of the release-version. The advantage of the VCS modules would be that you automate this. By suffixing your module-version with the target kernel release, you suddenly also support custom kernels, outdated kernels, etc., and there is no change required when the kernel is updated.

Couldn't the pkgver() function just use the version from

pacman -Q linux${_kernelname} | sed -r 's/linux'"${_kernelname}"' ([^-]+)-[0-9]+/\1/'

Then use the same code to set the versioned depends for package() instead of setting the versioned makedepends from the $pkgver variable. It doesn't matter which makedepends version you have, because you're guaranteed to have it either way whereas you do want to restrict the runtime depends, but that already works.

Not sure I follow. You mean setting `makedepends=('linux-headers')`, and then relying on the fact that the linux-headers version always matches the kernel version? And since you query the kernel version to set your own version, you effectively get the fixed dependency.

Hmm, this sounds good to me.

For example https://paste.xinu.at/5NK412r/


This just adds:

depends=("$(pacman -Q linux${_kernelname} | sed -r 's/ /=/;s/(.+)-([0-9]+)/\1/')")

to the package() function of the broadcom-wl package in [community].