Precedence: list
MIME-Version: 1.0
In-Reply-To: <20180123154751.GA10964@crute.us>
References: <CAN19L9GRSPJinpOC1NxHhv4gbuEf=GWF9B03xfP4aBWPYZN+zg@mail.gmail.com>
 <20180123154751.GA10964@crute.us>
From: Martin Galvan <omgalvan.86@gmail.com>
Date: Tue, 23 Jan 2018 16:34:35 -0300
Message-ID: <CAN19L9GoOkiK-fCFftOKX2u_PuYqV4x57E2gFgTDCoR5=NA0sg@mail.gmail.com>
Subject: Re: [alpine-devel] APKBUILD for kernel modules
To: Mike Crute <mike@crute.us>
Cc: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

2018-01-23 12:47 GMT-03:00 Mike Crute <mike@crute.us>:
> I built a kernel module package recently and there really aren't a lot
> of good docs for this. As I understood the rationale for co-versioning
> modules with the kernel it's about compatibility. A module is guaranteed
> to be compatible with the kernel it's built against but not necessarily
> against newer or older kernels, thus it doesn't make sense for the
> module to maintain it's own version but rather to adopt the version of
> the kernel it's built for.

I understand. I thought a APK package would do something for me like
packages generated by dkms-mkdeb do: give the module sources to the
user, then rebuild the module in the target system for its running
kernel. Now I understand they're designed for distributing binaries.
What it's not fully clear to me is how the module binaries are
distributed. What if a user with an older kernel updates their aports
tree, then tries to apk add a module package? How does the apk
machinery know which binaries to provide?


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---