It puzzles me that the instructions get you to build the kernel in-situ.

What's wrong with using a SlackBuild script that builds the kernel and makes a package that could be installed or uninstalled instead? Patrick includes a SlackBuild for the kernel in his sources directories although this assumes a compiled kernel. It should be easy enough to modify this script so that it also compiles the kernel as well.

I gather that "make oldconfig" and "make menuconfig" would still run interactively from within a script so you could still set your custom parameters. As long as "make modules_install" honours the DESTDIR option, you would have a build process that doesn't leave droppings all over the place should you have to remove the newly built kernel for any reason.

The script could also leave helpful messages like "Don't forget to modify lilo.conf and run lilo if you wish to use this new kernel" and other housekeeping messages as well.

Is there a difficulty I haven't thought of?

What do you need besides the SlackBuilds already shipped in the /source/k/packaging-<arch> directories?

As I said, those SlackBuilds don't compile the kernel - only make a package out of a compiled kernel.

Then IMO you do not need a SlackBuild to clean the house, a very simple shell script will do. Take as a basis the /source/k/README.TXT and just add the steps to (re)configure, make the kernel, make the modules, package & clean what needs to be. Then use or adapt the aforementioned SlackBuilds to build the packages. You can even use the rpm-pkg target if you wish, as _it's_your_machine_

You are missing the point. From the README.TXT:
This is telling you to use the global directories.

I want to know if there would be any problem with using $PKG/usr/src etc instead.

No. You can put the kernel source anywhere you want. /usr/src is just the place where the kernel-source package puts it. For instance you could have PKG=$HOME/work_in_process and download the source tarball there, or if you just want to re-configure a Slackware kernel, install the source package then cp -ar /usr/src/kernel-<version> $HOME/$PKG. I personally do not see any advantage in changing the location of the kernel source, but there is no inconvenience that I can think of either. Bear in mind tough if you compile programs that stuff that need kernel sources to be compiled won't look for it there, so if you need to compile something I suggest you keep the original source in /usr/src

PS instead of cp -a you could use the -root option of 'installpkg' but I have no experience doing that.

Actually the kernel install routine does create 2 symlinks back to the source under /lib/modules/(kernelversion)/[build/source]

These symlinks exist so that automated kernel module builds from things like nvidia and virtualbox work in a simple manor.

If you put the source in an arbitrary location and built the system from there and then later moved the source to the normal location of /usr/src then those links would no longer be valid.

1 members found this post helpful.

I use a few scripts to automate compiling myself. To keep things clean, run
instead of just make, and copy the bzImage to the packaging directory instead of doing a potentially messy `make install`. For installing the modules, use
Note that some (all?) kernel versions will still dump stuff in /path/to/directory/lib/firmware for no reason with `make modules_install` so you will have to remove that directory before creating a Slackware package. If you do use INSTALL_MOD_PATH it will still create bad symlinks to the kernel source as it was when building. You can just hack those into place...
Then makepkg will remove the symlinks and add their creation to doinst.sh.

I make packaging directories for {kernel,kernel-modules,kernel-source} and package them appropriately. Hacking the symlinks in the modules package also allows me to compile as a non-root user -- I just `chown -R root:root` each packaging directory before makepkg'ing each package. (FYI I do a permissions verification step to make sure the file permissions are OK for each packaging directory before packaging them up...) Of course, I don't actually run these commands...I have a building script to run as a user, a verification script also run as a user, and a packaging script run as root.

In short, nothing is preventing you from writing a script to do all that you want. However, Pat may manually massage certain kernel builds before packaging so there isn't an official do-all SlackBuild. (Note: that is merely speculation)

3 members found this post helpful.

This might be helpful:
http://distro.ibiblio.org/amigolinux...l-kiss.src2pkg

1 members found this post helpful.

You're welcome to use mine


P.S. If you do try it, don't worry about all the zero length file warnings for the header files that makepkg throws out That is normal. I've been meaning to mask them but just haven't gotten around to it.

.

1 members found this post helpful.

At last! Somebody who doesn't think this is a pointless idea. Obviously, I would prefer to do my first ever kernel build as somebody other than root. Eric's instructions are clear enough but you can still do a lot of harm if you are the root user - especially if you have made a mistake and have to trawl through the system directories removing the stuff you just installed.

That all seems clear. It is consistent with Eric's instructions and I actually discovered the INSTALL_MOD_PATH when examining the Makefile. I wouldn't have thought to delete the $PKG/lib/firmware as I would have assumed that was an important part of the process (Eric doesn't say to do that).

Interesting the bit about symlinks. Previously when making SlackBuilds, I have been creating my own doinst.sh to deal with symlinks. Now I know that makepkg will do that for me (you never stop learning when you are a Slacker ).

I don't think I need 3 separate scripts. My usual strategy is, once I am satisfied that the SlackBuild works properly when I run it as a user, I then run it as root. The SlackBuild template (available from SlackBuilds.org) actually includes instructions to make sure all files are owned by root and all permissions are 755 or 644 (naturally I have to comment out the chown instructions when I am not root).

That's good advice. Once I have a SlackBuild script, it should work for any kernel (I can even make it work for generic and huge kernels) but after any Slackware upgrades, I should examine Patrick's kernel SlackBuilds just in case he has added some new tricks (it all looks standard for 14.0).

Ah! It looks like I am re-inventing the wheel. Both these scripts will be immensely helpful when I am doing my own SlackBuild. I could of course, used them as is but one of the reasons I became a Slacker is that I like tinkering.

Since a kernel.SlackBuild seems to be straight forward enough, I will mark this thread as solved.

Yep, tinkering is what Slackware is all about. Best of luck with your script.

Here's the script I use, for what it's worth.
http://melikamp.com/features/slackbu...-common.tar.gz

1 members found this post helpful.

In the past Slackware shipped firmware from each kernel version so throwing firmware from the new kernel in /lib/firmware was fine (though really when making Slackware packages, the modules/firmware packages should be separate anyway so it would have been better to remove the spam in $PKG/lib/firmware from the `make modules_install` command anyway and run a separate `INSTALL_MOD_PATH="$PKG-firmware" make firmware_install` to create a firmware package -- but since Eric's instructions don't make a package [AFAIK -- been a while since I read them], any spam from `make modules_install` would produce valid firmware files anyway so it wouldn't matter). However, now Slackware ships firmware from upstream (git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git) rather than the firmware included with each kernel version. So as of 14.0 there is no point in including additional firmware files, so removing spam from that `make modules_install` command is a good idea. (Note: you *can* use the firmware from each kernel version but it just means an extra package, and to keep things kosher, if you do it that way you're better off using /lib/firmware/$(uname -r) instead of just /lib/firmware so you don't overwrite anything).
The reason I use at least two scripts is so I can run the building script as a non-root user in case there is a problem in the Makefile that would otherwise spam the system (though this would be unlikely, the kernel does change a lot and mistakes can creep in). So in my case two scripts are necessary since I only want root doing known chown/packaging commands to reduce any potential problems. If you're happy with the risk of compiling kernels as root then that's your decision.

No matter which user makes a package, only root can install it. I would never su up until I was convinced that all the bugs were removed from the slackbuild.