New style of kernel26 PKGBUILD and KISS principle.

Coacher · 2009-12-30 18:55:37

Hi, all.
The new version of kernel at last in the core repo. Nice present from arch-developers for new year.

Let's see what's new!
While I was looking through the kernel26 PKGBUILD from abs, I found some surprises.
Now it contains the union of PKGBUILDs for kernel26, kernel26-firmware, kernel-headers. Interesting.
Also, it builds all the three of them altogether (well, /var/abs/core/kernel26/PKGBUILD does).
Then the other PKGBUILDs modified too?
But the PKGBUILD for kernel-headers remained the same style as before, just version changed.
Wow. The PKGBUILD for kernel26-firmware remained the same style too, but the version changed to 2.6.31!
I've made about ten syncs with abs today, but nothing changed.

So, questions:
1. This new style of kernel26 PKGBUILD fits KISS principle bad, isn't it? If there any good reason to change it from how it was before?
2. Bug with kernel26-firmware PKGBUILD should be fixed.)

Last edited by Coacher (2009-12-30 18:56:18)

Allan · 2009-12-30 21:07:09

http://bugs.archlinux.org/task/17655

Note that you are wrong with "kernel-headers" as that package is part of the toolchain and nothing to do with the kernel.

klixon · 2009-12-30 21:28:38

Allan wrote:

Note that you are wrong with "kernel-headers" as that package is part of the toolchain and nothing to do with the kernel.

hope noone minds a little clarification here. As i understood it, there's now a kernel-headers package (sanitized kernel-headers for use in userspace, which has always been there) and a kermel26-headers package (the new one, containing a stripped-down version of the kernel source-tree, with enough left to build modules against it).

kernel-headers doesn't need to be the same version as the running kernel. It needs to be the same version glibc was built against.
kernel26-headers needs to be the same version as the running kernel, as you need it to build modules that are to be inserted into the running kernel

hth

Coacher · 2009-12-31 15:38:12

Allan wrote:

Note that you are wrong with "kernel-headers" as that package is part of the toolchain and nothing to do with the kernel.

Oops. My mistake. It is kernel26-headers. However, my question was the other.
Here is the PKGBUILD for kernel26 package version 2.6.31.6
http://www.pastebin.ca/1733107
Here is the PKGBUILD for kernel26 package version 2.6.32.2
http://www.pastebin.ca/1733109
Now it contains building script for three packages. What is the reason for complication?

wonder · 2009-12-31 15:49:34

i don't see any complication. is more clean and more easy for the packager to build from one running command rather than 2 or 3.

mechmg93 · 2009-12-31 16:18:14

klixon wrote:

kernel26-headers needs to be the same version as the running kernel, as you need it to build modules that are to be inserted into the running kernel
hth

in my laptop i have kernel 2.6.30.6 but the latest kernel26-headers package. I was able to compile the virtualbox modules without any problems. Ho did i manage to do this if theoreticaly i need same version of kernel26 and kernel26-headers?

klixon · 2009-12-31 16:31:13

because, when that 2.6.30.6 kernel-package was built, there was no split-out kernel26-headers package, and the kernel26-package installed those headers on your harddrive.
If you run that old a kernel, you have no need for the kernel26-headers package at all ^^

mechmg93 · 2009-12-31 19:45:41

thanks a lot for the answer Klixon

Surgat_ · 2010-01-02 14:18:34

Then, what's the reason for changing from kernel26 and kernel26-firmware to kernel26, kernel26-firmware and kernel26-headers? It sounds to me like a move to save disk space in systems that don't need to build modules, but isn't that what Debian does, as opposed to Arch (splitting packages in *-dev and so on).

ngoonee · 2010-01-02 22:39:41

Surgat_ wrote:

Then, what's the reason for changing from kernel26 and kernel26-firmware to kernel26, kernel26-firmware and kernel26-headers? It sounds to me like a move to save disk space in systems that don't need to build modules, but isn't that what Debian does, as opposed to Arch (splitting packages in *-dev and so on).

Its only done as a special case in the kernel, not for every tom, dick, and harry package.

There was reasoning in the [arch-dev-public] ML if you're interested, a couple of months back.

ConnorBehan · 2010-01-05 16:39:39

There are more drastic examples of where you'd want split PKGBUILDs. Libpurple is now required by telepathy-haze as well as pidgin stuff. So libpurple is now built alongside pidgin and finch from one PKGBUILD.

Also, there used to be about 15 mesa related PKGBUILDs but now there's one. You used to have to download the source, compile libgl, libglu and libglw, delete libgl and move libglu and libglw into pkg to create the "mesa" package, then download the source again and compile libgl again and move it into pkg to create the "libgl" package. The way it's done now really saves time.

And php? I've never tried to compile it but the PKGBUILD looks epic.

Arch Linux

#1 2009-12-30 18:55:37

New style of kernel26 PKGBUILD and KISS principle.

#2 2009-12-30 21:07:09

Re: New style of kernel26 PKGBUILD and KISS principle.

#3 2009-12-30 21:28:38

Re: New style of kernel26 PKGBUILD and KISS principle.

#4 2009-12-31 15:38:12

Re: New style of kernel26 PKGBUILD and KISS principle.

#5 2009-12-31 15:49:34

Re: New style of kernel26 PKGBUILD and KISS principle.

#6 2009-12-31 16:18:14

Re: New style of kernel26 PKGBUILD and KISS principle.

#7 2009-12-31 16:31:13

Re: New style of kernel26 PKGBUILD and KISS principle.

#8 2009-12-31 19:45:41

Re: New style of kernel26 PKGBUILD and KISS principle.

#9 2010-01-02 14:18:34

Re: New style of kernel26 PKGBUILD and KISS principle.

#10 2010-01-02 22:39:41

Re: New style of kernel26 PKGBUILD and KISS principle.

#11 2010-01-05 16:39:39

Re: New style of kernel26 PKGBUILD and KISS principle.

Board footer