X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail-ew0-f180.google.com (mail-ew0-f180.google.com [209.85.219.180]) by lists.alpinelinux.org (Postfix) with ESMTP id 2C8D91EC80C for ; Tue, 7 Apr 2009 20:54:41 +0000 (UTC) Received: by ewy28 with SMTP id 28so2682566ewy.25 for ; Tue, 07 Apr 2009 13:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X2CLzzHkKBgcHihmXxaNE4x8J3i0IVomJYNBlISfwhQ=; b=MHbkuNqmK0Fq0bLqu6ajci6M6mcwUwCthXtVguadRvAu2dtz49cFeHEk01tLzchvSG sMLQQSIUcz8bL13AYy0FtCM9s/sOf3kzbvZ+xBSSBIC+XfvkJVk3z5BV4YMLAPR0LYqK 4xJtYvy6lOZsMwqcwQkZ9DUnnqJFgEw1mec4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DVwEbeuRRvpPekn7d6HA/zhxS2vF+hn5Qevt8JDWFXNDgOkzXMwF1nQZh+gbo4rrtm dPJirYvGNSVVqc1TycJIlj20GwuvqI1SLg54sCDVjBKx3+1nyoxirQj+oOF6BykmWq6L tenOWsb4vAGvdE2jC/SnPAIxKEHRzONp0jDqs= X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.220.73.134 with SMTP id q6mr1073721vcj.51.1239137679334; Tue, 07 Apr 2009 13:54:39 -0700 (PDT) In-Reply-To: <1239116482.15720.95.camel@nc> References: <1239110538.15720.63.camel@nc> <49DB58C3.4080505@iki.fi> <531b02ea0904070725u7318f7bfu40eb9d4f758b2ef9@mail.gmail.com> <1239116482.15720.95.camel@nc> Date: Tue, 7 Apr 2009 15:54:39 -0500 Message-ID: <531b02ea0904071354r3e287d02n2713f4f84b25a084@mail.gmail.com> Subject: Re: [alpine-devel] dealing with kernel module apkbuilds From: Cameron Banta To: Natanael Copa Cc: =?ISO-8859-1?Q?Timo_Ter=E4s?= , Alpine-devel Content-Type: multipart/alternative; boundary=0016363b7c7034635f0466fd39ac --0016363b7c7034635f0466fd39ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/4/7 Natanael Copa > ok, now we are talking. What I need is some help with ideas how to > implement it and I think I got some ideas here. > > basicly, this would mean that you would need to tag a certain apkbuilds > to be either a normal apkbuild (no tagging?), to be a kernel apkbuild, > or to be a kernel module apkbuild. > > examples: > > cd dahdi-linux > abuild # builds packages with suffix for all kernel flavors > abuild -K grsec # builds only dahdi-linux-grsec > > cd linux-grsec > abuild -m # builds kernel + it scans the aports tree for packages > # tagged as module apkbuild, increases pkgrel and > # rebuilds. > I would suggest that abuild (or abuild-mod) appends the kernel version and pkgrel to the pkgrel on any kernel modules to create a dynamic version, instead of updating the version every time you build it, whether you've changed it or not. Also, it'd be nice if abuild automatically set the dependancy to the kernel, too. > > Maintainer would still need to commit those modified apkbuilds. > > I wonder if we could have a separate tool rather than include that in > abuild script. maybe abuild-mod/abuild-kernel. > What would happen if someone ran abuild instead of abuild-kernel/abuild-mod? And, I'm not familiar with the inner working of the abuild script, but I would guess there would be a lot of similar code shared between abuild and abuild-mod/abuild-kernel. What about installing a kernel module? Does the user have to figure out the right version himself? e.g: apk add my-kernel-mod-gresec-2.6.27.19 I think apk-tools might need to be modified to automatically search for the modules for the current kernel. e.g: apk add my-kernel-mod would add the version of my-kernel-mod for the currently running kernel - with the option of using the first example if needed. (Like on a system with multiple kernels installed.) -Cameron --0016363b7c7034635f0466fd39ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/4/7 Natanael Copa <natanael.copa@gmail.com>
ok, now we are talking. What I need is some help with ideas how to
implement it and I think I got some ideas here.

basicly, this would mean that you would need to tag a certain apkbuilds
to be either a normal apkbuild (no tagging?), to be a kernel apkbuild,
or to be a kernel module apkbuild.

examples:

cd dahdi-linux
abuild =A0 =A0 =A0 =A0 =A0# builds packages with suffix for all kernel flav= ors
abuild -K grsec # builds only dahdi-linux-grsec

cd linux-grsec
abuild -m =A0 =A0 =A0 # builds kernel + it scans the aports tree for packag= es
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# tagged as module apkbuild, increases pkgr= el and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# rebuilds.

I would suggest that abuild (or abuild-mod) appends t= he kernel version and pkgrel to the pkgrel on any kernel modules to create = a dynamic version, instead of updating the version every time you build it,= whether you've changed it or not.

Also, it'd be nice if abuild automatically set the dependancy to th= e kernel, too.

Maintainer would still need to commit those modified apkbuilds.

I wonder if we could have a separate tool rather than include that in
abuild script. maybe abuild-mod/abuild-kernel.

What would happen if someone ran abuild instead of ab= uild-kernel/abuild-mod? And, I'm not familiar with the inner working of= the abuild script, but I would guess there would be a lot of similar code = shared between abuild and abuild-mod/abuild-kernel.

What about installing a kernel module? Does the user have to= figure out the right version himself?=A0 e.g:
apk add my-kernel-mod-gre= sec-2.6.27.19

I think apk-tools might need to be modified to automat= ically search for the modules for the current kernel. e.g:
apk add my-kernel-mod
would add the version of my-kernel-mod for the cur= rently running kernel - with the option of using the first example if neede= d. (Like on a system with multiple kernels installed.)

-Camero= n

--0016363b7c7034635f0466fd39ac-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---