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: > 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. 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. Cu, knurd _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
