Kernel upgrade using patch files

patch on some book xmls

I'm against this idea. It would require two downloads to get the current version.

The main goal of LFS is to create a book which provides instructions to create a Linux OS. These books are released semi-often and we expect users to use the version of the kernel specified in the book (or the most current version of the 2.6.x series).

Either way it is *one* download.

It would be okay, however, to mention that if you want to upgrade your kernel to a newer version of a particular series of kernel (2.6.x), *and* you kept your original kernel tarball (or expanded tarball directory structure), you could simply download the current patch file to update your kernel dir structure.

But I wouldn't make it the primary method of building/downloading the kernel sources.

In Yekaterinburg, Russia, using patch files means huge monetary savings for those following the development version of LFS. Reason: downloading 1 megabyte costs $0.2 ("unlimited" plans are a joke - they include 3 GB/month cap, and after exceeding this, the contract is automatically terminated).

No doubt, it's a very good practice to keep updated the kernel tree by using patches, instead (by wasting bandwidth) to download every new release. I had proposed the same thing in Jhalfs and Manuel made a patch for this.

However I am not really sure if it worth adding this methodology in the installation of linux-headers. But I am sure, there is a place for a note in the chapter08 (the kernel installation) and even (and again as a note) in the first installation of linux-headers in chapter05. Its for a good purpose and as I said its a good practice and it should transformed into a habit.

Or even better in chapter 3.1 (Introduction).

Still, actually using the stable patch as the default method of obtaining the latest linux fixes would benefit me as a maintainer of the LiveCD. Reason: the book includes the MD5 sum of the stuff to download, and jhalfs checks this - so I should download this huge kernel myself each time it is updated, in order to build a CD with a working jhalfs.

I'm not sure how many people have the download limitations as Alex. I certainly sympathize. However, I feel the default instructions should reflect fetching the full file. For Debian files, you often, if not always, need to download the main file and a path file. For most, this is just extra work. Also, you have to download a whole file anyway for major revision levels.

There are a lot of large files in building a LFS system, and I'm not sure all have patches. Although the kernel is the largest file, gcc is almost as large. BLFS has several very large files or groups of files including gimp, kde, gnome, and X.

A paragraph or two in the intro to Chapter 3 would be appropriate, but that's all I thionk should be done.

Could this be suggested as a BLFS process, eg: you build the book with the current approved/supported kernel, then as a BLFS process you can patch up to version X+1

The other thing to consider is that patching the kernel before initial build will mean different kernel and header versions being used, which means if the builders are changing this sort of information in the book, they should know how to use a patch file in the kernel, keep in mind the assumptions of the users ability.

This should be addressed in milestone 6.4. It really should be a text change in the appropriate place(s) -- Chapter 3 and or Chapter 8.

Added a paragraph to the note in the packages page explaining that bandwidth can be saved when making multiple updates within a minor kernel release by downloading a base version and patches.

Fixed at revision 8675.