As of now /etc/genkernel.conf is a mixture of two different types of options: 1. User configured options which are rarely changed and which are mostly independent of package version (CLEAN="no", MOUNTBOOT="yes", LVM="yes" and others) 2. Package constants which strictly depend on package version and often change with upgrade (BUSYBOX_VER="1.7.4"). As a result of such setup user is forced to go through a long process of updating the /etc/genkernel.conf with every package update. Reproducible: Always Expected Results: I see two options to simplify the situation: 1. Add /usr/share/genkernel/genkernel.conf with default values, and values from /etc/genkerlnel.conf would simply override default values Similar to /usr/share/portage/config/make.globals and /etc/make.conf 2. Split two groups of options into two different config files.
Point is clear. As a workaround, for often-changing options you could leave them untouched at genkernel.conf and control them from the command line. For a real fix, we will need a patch from you.
The workaround is like a vicious circle. I used to use them, but then I thought "Hey, why don't I just add all the options in config file instead of remembering all those long command line options". Then comes new update with config changes and I think may be I should use command line options insteadd of this messy config file. Anyway. I'm attaching patches for 3.4.16. It's pretty simple, so should be easily adjustable.
Created attachment 284851 [details, diff] split config file
Created attachment 284853 [details, diff] ebuild patch
I'm worried about a few things with the current patch approach. Misc thoughts: - By convention, config lives in /etc/, not /usr/share/ - genkernel's parameter --config=file currently allows to override all of genkernel's config. The current patch, breaks that feature. There may be need for --config-master= and --config-utils= or something. - Instead of letting genkernel source the second config, the master config could take that over. May have good and bad consequences. - Maybe introducing a folder /etc/genkernel/ and splitting even more makes sense while we're at. I'd love to hear thoughts on this from more people before taking action.
This was addressed long time ago via https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=6d35693a8b8c0baa95b20e4b41ef22eb981a5daa
