Talk:Kernel/Arch Build System
- I am doing this now and 2 dependencies have shown up that are not documented, bc and xmlto. Or maybe these used to be installed with base-devel but no longer are.
- If somebody want to keep stock kernel beside custom one, shouldn't be the "provides" array uncommented, and changed to
provides=('kernel26' 'linux') ? --4javier 05:27, 10 January 2012 (EST)
- should I also uncomment these parts in package_linux-headers() and not only in package_linux()? --Onny 11:08, 8 March 2012 (EST)
- this page does not mention that every changed .config-file has a new md5sum which should be added into the PKGBUILD --Onny 11:24, 8 March 2012 (EST)
Installing, best practice
The "installing" section suggest that the best practice is to install the kernel headers package first and then the kernel itself.
Shouldn't the best practice be to install them together and then let the hooks do their job? Installing the kernel-headers package alone will trigger the dkms hook anyway (is this a bug?), which obviously will fail since the new version of the kernel is not yet installed. Kyleh (talk) 13:50, 4 October 2016 (UTC)
- Agreed they should be together, and changed this. Just had someone in IRC run into a DKMS problem by trying to install headers alone and first. Jamespharvey20 (talk) 03:30, 30 April 2019 (UTC)
Rename linux.install instruction ambiguous
This is ambiguous: "Depending on the PKGBUILD you may have to also rename linux.install to match the modified pkgbase." An example of what to change it to based on some hypothetical value of pkgbase would be helpful.
90-linux.hook, and perhaps a few other files, have a
%PACKAGEBASE%directive that will be filled in automatically if
PKGBUILDis edited to have:
% grep '^.\?pkgbase' PKGBUILD #pkgbase=linux # Build stock -ARCH kernel pkgbase=linux-custom # Build kernel with a different name