DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer
         :content-transfer-encoding;
        b=tKa9oJKzjMB5GhFVElaW75qS40sK/UOH/IXMTBLwBkhvF3DEB2K5NNr/RsjXN3bLRs
         fqs/MWASb6Sohw2GO0PwJfBrWf18KknVRMBMJGJRRfWVWpNwR9rJbf+pDbEij/MBEUXc
         4oYYVYm2Qmc20b5IyJhx7jIpvf6RByDhruuKI=
Subject: [alpine-devel] dealing with kernel module apkbuilds
From: Natanael Copa <natanael.copa@gmail.com>
To: Alpine-devel <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain
Date: Tue, 07 Apr 2009 15:22:18 +0200
Message-Id: <1239110538.15720.63.camel@nc>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

I have an issue with building kernel module packages. Basicly, whenever
you rebuild the kernel you need to rebuild the kernel modules packages
(i.e dahdi-linux and xtables-addons, iscsi will come soon too)

The goals are:
* you update or rebuild the kernel, and all separate kernel module
packages gets rebuilt automatically.
* be simple. newbies should be able to read the apkbuild and understand
whats going on
* the kernel module packages should increase the pkgrel when rebuilt so
that you dont end up upgrading the kernel but not the kernel module
packages.

Currently, if kernel is updated I need to remember to manually go to all
kernel packages an bump the pkgrel. Ideally this should be done
automatically.

As I can see there are 3 ways to solve this:

1. build all kernel packages in the kernel APKBUILD.

The benefit is: if you rebuild kernel, you rebuild all kernel module
packages. The kernel module ackages inherits the kernel version so for
example dahdi-linux will have the version 2.6.28.9-r4 or similar.

The drawback is that you will rebuild the kernel if you update for
example dadhi-linux. If you want to add more non-standard kernel modules
you will need to modify the kernel APKBUILD.

2. we include the kernel version in the kernel module package pkgver.
This is doe by sourcing the kernel APKBUILD. For example:

# source kernel version
. ../linux-grsec/APKBUILD
pkgname=dahdi-linux-grsec
_dahdiver=2.1.0.4
pkgver=$pkgver.$pkgrel.$_dahdiver
pkgrel=1
...

If kernel is 2.6.28.9-r4, the dadhdi-linux-grsec would here end up as
2.6.28.9.4.2.1.0.4-r1

Alternatively we could just add the pkgrels so reduce one digit:
# source kernel version
. ../linux-grsec/APKBUILD
pkgname=dahdi-linux-grsec
_dahdiver=2.1.0.4
_rel=1
pkgver=$pkgver.$_dahdiver
pkgrel=$(( $_rel + $pkgrel ))
...

In this example we would end up with
dahdi-linux-grsec-2.6.28.9.2.1.0.4-r4

If we now upgrade the kernel to 2.6.28.9-r5 then will 'abuild up2date'
detect that the package is missing and will trigger a rebuild and things
just works. However, it is somewhat hackish, creates ugly version
numbers and is not so simple.

3. the third option is to do more or less what we do today, but have
some kind of sanity check scripts that keeps track on the kernel
versions and kerlen package versions and will make buildrepo fail if the
kernel module package is out of sync with the kernel package. This
requires that maintainer manually bump the pkgrel in the kernel module
APKBUILD. we could have some helper scripts to make that job easier.
Benefit here would be tat its less hackish (no need for the ugly
sourcing of other APKBUILDS) and we have nice version numbers,
dahdi-linux-grsec-2.1.0.4-r2 instead of
dahdi-linux-grsec-2.6.28.9.4.2.1.0.4-r2 or
dahdi-linux-grsec-2.6.28.9.2.1.0.4-r5.

But the drawback is that it will not auto rebuild if kernel is updated.

What do you prefer?

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---