On 12/07/2016 01:16 AM, Thorsten Leemhuis wrote:
On 06.12.2016 19:46, Laura Abbott wrote:
On 12/06/2016 04:44 AM, Thorsten Leemhuis wrote:
Lo! On 21.11.2016 19:46, Laura Abbott wrote:
As a follow up to the previous discussion about kernel configuration in Fedora (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org...) I have a prototype of what a method of keeping each configuration file in a separate file would look like. This method takes care of several of my gripes of the current version (and found a few errors in the existing config files). The biggest question I have is if this will scale for how frequently Fedora adjusts configuration options. Some of that could possibly be solved with more scripting improvements.
[…]
- Just thinking aloud: I wonder if the pre-generated *debug.configs are
a good idea. Wouldn't it be more obvious what is happening if we'd ship one base config (e.g. where debugging is turned off) and then have something in the spec file itself that builds slightly modified version depending on what is needed in the current build? Having a mechanism like this might be handy for other situations as well. For example we could have something in the spec file that automatically disables "CONFIG_ARM64_VA_BITS_48" and "CONFIG_ARM64_VA_BITS" when building for "$fedora_release <= F25"; this way we'd make sure things like that do not accidental make it into older releases during a rebase.
I'm not sure how that would be more obvious. Generating the configs makes it easier to check each file to see what's present vs not being able to see what's enabled until it is built. I'm wary to put anything more in the .spec file than we have to since the file is complicated enough as is.
Yeah, I can see that (albeit I found the "generate_(all|debug)_configs.sh" scrits a bit confusing at first and would prefer to see the commands directly in the spec file). But OTOH:
The amount of code in those scripts used to be much bigger so I can look to pull those functions into the spec file.
Having the spec file enforce config policy would be a step in the wrong direction.
I tend to think: putting too much tricks into our SCM is the wrong direction. Sure, it might make things easier to maintain for Fedora developers. But it's not a fedpkg checkout advanced users start with when they want to build a modified package -- instead it's typically the SRPM they will use as base. That's why we have individual patches there and that's why I think some logic is better suited there -- for example when it comes to configurations options that are better disabled (ideally automatically!) when you rebuild a rawhide kernel on the latest or and earlier Fedora release.
Right but all the individual CONFIG_FOO=y files are not present in the RPM. Only the fully generated kernel-$arch.config are present in the SRPM. I updated the latest version to have config-local (renamed to kernel-local) so options can be added there as well.
The decision of whether or not to use the debug config for rawhide is already controlled via %define debugbuildsenabled. Is there more logic you would like to see expanded apart from that?
The latter is something I do, so I obviously have a interest to make that easy. Thus I wanted my voice to get heard in this discussion, which I archived now, so I'm happy :-) IOW: it's not a big issue for me, I'm fine with putting this subthread to a rest now.
Appreciated!
Cu, knurd
Thanks, Laura