[aur-general] Kernel version requirement
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). 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 ?
On Tue, 2019-05-07 at 21:25 +0200, 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).
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 ?
You would probably want to omit the dependency entirely on top of dropping the version requirement (since linux is part of base). I assume the reason that linux-lts, and other kernel packages don't have a provides field (and why my AUR package, linux-vfio, omits this as well) is because they do not provide linux, they provide an alternate kernel (e.g. linux-lts provides linux-lts, not linux; linux-vfio provides linux-vfio, not linux). Mark
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 provides=(java-runtime=$majorver) -- Eli Schwartz Bug Wrangler and Trusted User
On Tue, 2019-05-07 at 15:47 -0400, Eli Schwartz via aur-general wrote:
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 provides=(java-runtime=$majorver)
This isn't quite the case for kernels though. The kernels in the official repositories don't provide a line like "provides=(kernel=$pkgver)" type of line. Is there a plan to change this to include such a line in the packages? Mark
On Tue, 07 May 2019 15:56:47 -0400
Mark Weiman
Is there a plan to change this to include such a line in the packages?
Mark
No, because they don't provide the same thing as the linux package.
On Tue, 7 May 2019 at 21:26, Julien Nicoulaud via aur-general < aur-general@archlinux.org> 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).
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 ?
adding a condition to the .service file should be enough. https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Condition... -- damjan
participants (5)
-
Damjan Georgievski
-
Doug Newgard
-
Eli Schwartz
-
Julien Nicoulaud
-
Mark Weiman