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@xxxxxxxxxxxxxxxxxxxxxxx/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/) >>>> 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
