[aur-general] Kernel version requirement

Eli Schwartz eschwartz at archlinux.org
Tue May 7 19:47:23 UTC 2019

On 5/7/19 3:25 PM, Julien Nicoulaud via aur-general wrote:
> Hi,
> In the oomd package <https://aur.archlinux.org/packages/oomd/>, I put a
> linux>=4.20 dependency requirement since it requires the new resource
> pressure metrics <https://facebookmicrosites.github.io/psi/> introduced in
> linux 4.20.
> But as another user pointed out, some of the alternatives kernel packages
> declare provides=("linux=${pkgver}"), but several of the most popular do
> not (linux-lts, linux-dzen, linux-hardened).

Those packages are incorrect as they do not provide /boot/vmlinuz-linux
or /lib/modules/${version}-ARCH/, and are specifically designed to be
co-installable with the actual core/linux package. Their provides=()
will therefore cause errors for users who have installed out-of-tree
modules targeting a different kernel package.

linux-libre tries to get around this by also providing LINUX-ABI_VERSION
but AFAIK it is the only package to do so.

> What we would be correct way to handle this ? Should I just drop the
> version requirement (since having a kernel>=4.20 does not imply you are
> running this one anyway) ? Or should these packages be improved ?

Consider java (sorry!) for inspiration here. One can have java-runtime
as a dependency if an application can use any version of java, but if
you need a specific version of java, depend on e.g. java-runtime=11.
This does not guarantee the user will use this version, but it does
guarantee that they have it installed and provides pacman hints so that
users know why the software does not work on other versions.

This works because there is a standard for all java packages to

Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190507/e05fc4be/attachment-0001.sig>

More information about the aur-general mailing list