buildkernel.conf should not set variables supposed to be set by genkernel.conf

[leezu]

In case both buildkernel.conf and genkernel.conf set the same variable (e.g. ADDITIONALKERNELCMDS) the one in genkernel.conf takes precedence and the one in buildkernel.conf will be silently ignored. So I wonder, why in the first place encourage users to configure these variables in buildkernel.conf and not in genkernel.conf?

i.e. man buildkernel.conf says

          ADDITIONALKERNELCMDS
                 If you wish to pass any additional command line parameters in the kernel boot line (either for attention of the kernel itself, or  for  genkernel(8)'s
                 init(8) script), you can specify them here. All of the important values for booting will be set by buildkernel, so this defaults to an empty string if
                 not set.

                 One parameter you may wish to consider here is "root_trim=yes"; this will enable TRIM support on the encrypted LUKS partition (turned off by default).

[smhanes]

I'm probably missing something or your comment applies to version(s) of genkernel / buildkernel I'm not using, but buildkernel passes buildkernel.conf options to genkernel as command-line options, which per genkernel.conf precedence rules states command-line options will overwrite genkernel.conf options.

Since buildkernel is essentially acting as a customized wrapper for genkernel, it seems most appropriate to provide overrides in buildkernel.conf rather than in genkernel.conf.

[leezu]

Well, in the end either way works. To me it seems more intuitive not to duplicate the genkernel.conf and to then overwrite it though.

[sakaki-]

31 Oct 2020: sadly, due to legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and it may be of use to others); however, I plan no further updates, nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

With sincere apologies, sakaki ><