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
>>> 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
>> * 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
>> "$fedora_release <= F25"; this way we'd make sure things like
>> 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.