On 08/25/2016 12:53 PM, Paul Bolle wrote:
Hi Laura,
[It seems I just sent a reply to /dev/null. Let's try again.]
On Thu, 2016-08-25 at 12:08 -0700, Laura Abbott wrote:
On 08/25/2016 11:35 AM, Paul Bolle wrote:
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.
What is a _new_ option? For the upstream build system there are only
valid or invalid options.
Remember that upstream changes kconfig symbols as it sees fit (dropping
symbols, adding symbols, changing symbols from 'y' to 'm', etc).
I'm referring to us running oldconfig over all the config files
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel.spec#n1247
listnewconfig_fail is on by default so it forces us to specify new options.
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?
The upstream kconfig tools are extremely liberal. You can feed them an
outdated .config file and they'll always emit something. What they'll
emit might not be very usefull, but they'll _never_ error out. (If they
do error out that's a bug.)
This is true. Fedora is being more restrictive here. It's more useful
for maintenance though and leads to fewer surprises.
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.
The kconfig symbols are not stable and never will be stable, so issues
will pop up again and again.
Yes, and we will need to keep them in sync. This is part of the work
of kernel maintenance.
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?
No. I'll just repeat that configuration issues should be non-fatal.
(Please note that I still don't know what this patch exactly makes
fatal.)
I think this is where we are disagreeing. For an experienced individual,
accepting all configurations is the right thing to do. Mismatched
configurations have a much bigger impact for maintainers though
because a mismatched configuration is going to go out to many more users.
It's much easier just to reject bad configurations. The same is true
for newer users, if there's no error, it's much harder to go back and
debug a configuration issue versus just rejecting it outright.
Thanks,
Paul Bolle
Thanks,
Laura
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
