John Baldwin wrote: > I build a custom release at work that uses the a custom kernel by > default on 4.x and make use of LOCAL_PATCHES and KERNELS to accomplish > what I need. I do think I have a local patch that allows you to > specify the kernel config for the "default" kernel, but that it > doesn't apply to 5.x because 5.x does things differently in that > area. 5.x doesn't install a kernel.GENERIC anymore though, which is > a bit disturbing.
I have a local 4.x patch, as well. The 5.x stuff screwed up the world when sysinstall was moved, and it's only gotten worse, in that area. The LOCAL_PATCHES and KERNELS, as you've noted by having a local patch (8-)), isn't really sufficient. I don't *WANT* the thing to be named "GENERIC", and even if I wanted that, it's a practical impossibility, because my kernel source tree is checked out seperately from the res of the sources, which are checked out from the FreeBSD CVS tree. The reason is that the kernel is imported into a seperate source tree to support local modifications. This is a workaround to CVSup not supporting the idea of the local copy being placed on a vendor branch... effectively, this means that in order to maintain large local change sets, you have to checkout a FreeBSD version from CVS, check it into your own local repository (losing the history as you do this), and then stabilize it for your application, before making local modifications (if you can't have a vendor branch in your CVSup'ed replica: make one of your own). Basically this means you are well and truly screwed in the build process, if you want to rebuild, if your patches touch any of the standard file names, due to the update process when doing an update and rebuild of the system (you can do it, but expect your cycle time to go from about 1 hour to about 1.5 days, as everything ends up getting rebuilt, instead of just the things that change). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
