X-Original-To: alpine-devel@lists.alpinelinux.org Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lists.alpinelinux.org (Postfix) with ESMTP id E0A855C5C09 for ; Tue, 23 Jan 2018 15:47:54 +0000 (GMT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C7B6520CA6; Tue, 23 Jan 2018 10:47:53 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 23 Jan 2018 10:47:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crute.us; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=V4EZMR0675UgFzh+8mbkzSf9y9MqzRifSfsNK1u7Ew8=; b=zJBMm Xobvm9N3J9z2GgBZmntPKtlau7IvhKsoRXmgLaiZO4o4W9E5mo2tm7rGXdYLjoqa kvrBy9nSFkjme8fd+RjjvfRorCkqGBsPHcHEo/7+6OJuv7ZOZHzCcLziNKgAhiKK Kzig/auWHC35KkmyP5gPFsCwXL4B23sXj9Sf5A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=V4EZMR0675UgFzh+8mbkzSf9y9Mqz RifSfsNK1u7Ew8=; b=ouyc61QG9qhW3knfQtwKdQSnKzpTF5Xo1ehjfENE4K76v 9Rjv3KY9PdOV2n+bj7IoupY1Q7DIYBlBDN6IrV8mlePAQVU1oaWheiFLFKHHENQi QxLnNs9ep3Ja9vlnlOqRf/lrxQpKV5Hc42AYNtxw+zdgALbIovCle1E86xrqppbl WeldGsm9vvjQcFEE+RpiNUI/oJAhqZgLkmGgU8ZQ1o/gAbpVVifVI8TINWz4P2E3 izzpnfWWJBNaPKf81xj69mz1JH9JOkBJxPvKZdML78LATmBd7JKNrI/MpfOmvCKb 5zty0MzfrxeOARheWg56rxtkzmaX7aEh5BqHjbAYA== X-ME-Sender: Received: from crute.us (unknown [24.35.94.219]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F0E9246D8; Tue, 23 Jan 2018 10:47:53 -0500 (EST) Date: Tue, 23 Jan 2018 15:47:51 +0000 From: Mike Crute To: Martin Galvan Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] APKBUILD for kernel modules Message-ID: <20180123154751.GA10964@crute.us> References: X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 User-Agent: Mutt/1.5.24 (2015-08-30) On Tue, Jan 23, 2018 at 11:26:14AM -0300, Martin Galvan wrote: > I'm trying to write an APKBUILD script for a package that contains a > kernel module. Since there seems to be no documentation about this, > I've been looking at some examples (the *-hardened packages), and I've > seen that, if I understood correctly, all of them set a kernel version > (_kver) and refuse to build unless linux-$_flavor/APKBUILD's pkgver > matches _kver. Every time a new kernel version comes out, the APKBUILD > has to be updated to match the new kernel version. > > Is this done just to make sure the maintainer is aware of kernel > changes, and has to at least indicate so in the APKBUILD? What if we > wanted to distribute a module that worked on multiple kernel versions? 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. Here are the ABUILDs for the module: https://github.com/alpinelinux/aports/blob/master/testing/aws-ena-driver-hardened/APKBUILD https://github.com/alpinelinux/aports/blob/master/testing/aws-ena-driver-vanilla/APKBUILD > As a side note, I saw that the APKBUILDs look for > linux-$_flavor/APKBUILD in a relative path. I assume this means > they'll always run from wherever they're located in the aports tree, > but I saw that e.g. > https://git.alpinelinux.org/cgit/aports/tree/testing/ipt-netflow-hardened/APKBUILD > looks in testing for linux-$_flavor, which I didn't find. Does that > mean it'll always fail? You should always use the kernel out of the main tree and use relative paths to make sure you always get that kernel. The ABUILD you linked is will only ever run those tests when it's located in the main tree which strikes me as broken. > Finally, I saw that for failure cases there seems to be a 'die' > function that looks like perl's. Where can I find its definition? Is > it documented anywhere? That's defined in the abuild command itself which also defines the default methods for your ABUILD along with other utility functions: https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n103 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---