On 08/25/2016 11:35 AM, Paul Bolle wrote:
On Thu, 2016-08-25 at 09:16 -0700, Laura Abbott wrote:
On 08/25/2016 03:19 AM, Paul Bolle wrote:
The issue is that CONFIG_PWM_LPSS was set =m but it wasn't actually
set at all. See https://bugzilla.redhat.com/show_bug.cgi?id=1335196
as well.
Yes, I read that report.
We're setting these options so we think they are enabled
but in reality they aren't. This is confusing for both us and
the users. The goal here is to catch these problems at build time
so they can be corrected sooner.
How does this patch catch these problems? The patch description doesn't
tell us that. (Imagine reading the patch description while
bugzilla.redhat.com is unreachable. How much does one then know what
this patch is actually all about?)
Including an example of the output of "cat .mismatches", say for the
issue that this bugzilla link references, might do wonders for people
reading this patch description.
That's a good suggestion.
This terminates the build, doesn't it? But we should only terminate
the
build when we're unsure how to continue. Because otherwise we might
break people's build for configuration issues they personally
couldn't
care less about. For instance, I'm running an x86 laptop with
CONFIG_PWM not set ever since I run Fedora 24. Why should I care? I
have no idea.
We terminate the build because something is misconfigured. If an option
is set =m in the config fragments but not in the generated config someone
has specified something wrong.
No, we don't. We try to finish the build if that's possible. We might
emit warnings, but we try to keep the build going.
We terminate the build for newoptions that aren't specified. I consider
this in the same category.
I'm pretty sure these configuration mismatches only happen for rather
obscure corner cases. Serious configuration problems will never hit the
tree in the first place.
I consider a case where we have an option specified as =y or =m in our
configs and it gets generated as not enabled serious configuration
problems. What do you consider a serious configuration issue?
Imagine trying to rebuild the kernel package, for whatever reason,
locally and hitting this build error for something entirely irrelevant.
(Like an issue with CONFIG_PWM that is apparently not interesting for
your build machine.) Why on earth should we try to make people unhappy
by breaking their build for them?
It's not the goal to break a build for anyone. I don't plan on merging
or turning this on until existing issues are fixed up. Ultimately
people who are making their own builds though have always been, well
on their own. I can request people test with their custom configurations
to see if there is anything we are missing. There will be an option
similar to listnewconfig to skip the error out as well. Do you have
other suggestions about minimizing the impact?
There should be an option to ignore it though if people don't want.
Miguel, can you add an option similar to listnewconfig_fail?
Thanks,
Paul Bolle
Thanks,
Laura
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
