[arch-general] Kernel PKGBUILD proposition: Ease custom kernel compilation.

Tim Gelter tgelter at gurulabs.com
Sun Dec 7 17:38:44 EST 2008


Nicolas Bigaouette wrote:
> Hi all!
> 
> Since a couple of years of using Arch, I often wanted to compile a custom
> kernel, as many others did. There is many, many, many! forum threads about
> that, a couple of wiki pages too, with questions and howtos.
> 
> Many efforts has been put to create new PKGBUILDs[1-2] to ease the effort of
> this. Unfortunately, these PKGBUILDs suffer from some drawback:
> 1) They are placed on a wiki which can be edited by everybody. This mean it
> is not a trusted place to store a PKGBUILD, specifically one as vital as the
> kernel's.
> 2) They tend to be forgotten and not updated anymore. This can lead to an
> unbootable kernel, rendering all this useless.
> 3) They do not take advantage of the devs' work: They are the best one to
> trust for a quality PKGBUILD. They also have all the feedback from Arch
> users, bug reports, etc. They know what has changed in the kernel and what
> needs to be adapted for the installation, for example new "provides=()". A
> PKGBUILD from a wiki page or a forum post might be good at the time of post,
> but be outdated just days latter...
> 4) They build a kernel which is way different then the stock one, for
> example because they don't have the same patchset.
> 
> Users most often wants to build a custom kernel just to try it, change some
> configurations, add one or two patch, optimize for their own machines, etc.
> Maily, they just want to take the existing one, change a couple of things,
> and be ready. One also wants to install this kernel side by side with the
> stock one, at least until his own kernel is stabilized and running as
> wanted. Actually, Arch's stock kernel does not allow that.
> 
> What I propose is some simple modifications to the PKGBUILD so users can try
> to compile their own kernel based on the original, trusted, working and
> approved one. With theese modifications, one only needs to add a "kernel
> name" to the pkgname: "pkgname=kernel26-mykernel" for example. Nothing else
> is needed to compile a custom kernel. The created package would sit without
> problem side by side with the stock kernel. Also, if the pkgname is kept to
> "kernel26", then the stock -ARCH kernel will be built.
> 
> This approach has many advatanges:
> 1) The patch is relativelly small: not much is changed in the original
> PKGBUILD.
> 1) Nothing changes for the devs. They continue to provide a quality kernel
> to Arch users.
> 2) Users who wants to compile a custom kernel can just sync abs, change the
> pkgname and install a new kernel, in the KISS philosophy. They know that if
> they just change the name, they will have the same package so they can
> easily test whatever feature/patch/bug solution/optimization they want.
> 3) Because one only needs to change the pkgname, they use the devs' high
> quality, tried and truth PKGBUILD. When a new kernel is out, they can sync
> the devs' modifications easily.
> 4) Bugs affecting the kernel can be easily tested for solutions. Affected
> users just need to compile a "-testing" kernel where a patch is applied,
> install it and see if it works, without having to risk breaking his system
> by replacing -ARCH kernel with an unbootable one.
> 5) Better feedback to the devs since the users would be using (almost) the
> same PKGBUILD as the original one.
> 6) Simplify a lot all these "custom kernels" threads and wiki posts.
> 
> I did "maintained" such a patch for myself because I wanted to keep in sync
> with the original PKGBUILD. After posting it on the forum[3], I got some
> positive feedback. People reporting back said they liked the simplicity and
> the effectiveness of the method. They also positively tested it with
> different configuration. The patch should be applied to revision 19747 for
> i686 or 19749 for x86_64. It modifies the PKGBUILD and also slightly the
> kernel26.install and kernel26.preset file.
> 
> I am thus reporting this to be include in the official file. I think it
> would be a great addition to an already great distro. I am open to
> discussion on the subject. I hope I am posting this on the right mailing
> list and that it can be included! :)
> 
> Sincerely,
> 
> big_gie
> 
> [1] http://wiki.archlinux.org/index.php/Kernel_Compilation_with_ABS
> [2] http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS
> [3] http://bbs.archlinux.org/viewtopic.php?id=37579
> 
> 
+1
I used to run Lunar Linux and really liked the way each kernel upgrade
happened; it'd store a copy of your .config (or, in the case of
big_gie's recommendation, a copy of the arch dev's .config) away under
var, then download the kernel source, apply any patches, run a "make
oldconfig", then ask if you wanted to configure the kernel. If you chose
yes, it'd look at an environment variable and depending on what it
found, run "make menu{,x,g,q,}config" and upon saving the .config it'd
kick off the compilation and installation of the kernel. That's really
the only thing that I miss about Lunar since coming over to Arch.
Anyhow, it's just a feature request. :)

-Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-general/attachments/20081207/19e5be6e/attachment.pgp>


More information about the arch-general mailing list