On Thu, Aug 25, 2016 at 12:08 PM, Laura Abbott <labbott(a)redhat.com> wrote:
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.
I am guilty of thinking everyone involved in the kernel was aware of this
issue, so I figured a short commit message
was enough. I will provide more details in future patches.
Thanks Paul!
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?
>
>
Yes! It should be as simple as adding another macro similar to
listnewconfig_fail.
Thanks,
>
>
> Paul Bolle
>
>
Thanks,
Laura
--
Regards,
Miguel