Mail archive
alpine-devel

[alpine-devel] kernel module packaging

From: William Pitcock <nenolod_at_dereferenced.org>
Date: Sat, 5 Aug 2017 14:55:21 -0500

Hi,

As an initial step towards cleaning up the way we package kernels and
modules, I am presently looking at modules. I have some ideas about
that:

1. APKBUILD sourcing other APKBUILDs for variables:

In this case, we source the kernel APKBUILD to get the kernel version.
I think we should clean this up by introducing a function that sources
the APKBUILD inside the function and returns the requested variable,
so that the APKBUILD data doesn't leak into the main namespace.

2. APKBUILD declares $pkgver as the kernel version it is built for:

I believe this was a workaround for a defect in the solver that I
corrected last April that caused a broken upgrade transaction to be
computed. I believe that this approach is flawed as well, as we still
have to update the APKBUILDs when a new kernel is built, so we are
better off using the real version of the modules. With the solver bug
fixed, declared dependencies on the specific kernel version should
result in a depgraph break if the kernel it was built against is
unavailable; which means that the kernel and it's modules will be
safely excluded from the upgrade transaction.

3. Use of virtuals and provides to select the right modules instead of
install_if or similar rules:

Different APKBUILDs have different ways of pulling in the modules. I
suggest that we have, for example with zfs, zfs-hardened provides
zfs-modules while depending on linux-hardened. If zfs depends on
zfs-modules, then zfs-hardened will be selected if linux-hardened is
installed, which is less expensive than an install_if rule.

Let me know your thoughts.

William


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Sat Aug 05 2017 - 14:55:21 GMT