wpad-mesh-wolfssl gets automatically deselected in menuconfig due to a bug in hostapd Makefile

[ilario]

I am reporting this also on OpenWrt side, as it looks like a menuconfig bug rather than a suboptimal way on how to use it.

Selecting at the same time wpad-basic and wpad-mesh-wolfssl causes a clash of files installation in the compilation process. For this reason the deselection of wpad-basic has been suggested in 6e08d3e

wpad-mesh-wolfssl can be selected in menuconfig and wpad-basic deselected, until here everything ok.

Then when closing and opening again menuconfig, wpad-mesh-wolfssl is not visible

.

But when wpad-basic (or something else) is selected, wpad-mesh-wolfssl appears and is actually selected (as it should be).

The wpad-mesh-wolfssl package is categorized as being inside wpad-mesh-openssl, which makes no sense.

And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from here):

wpad-basic
  [identical part removed]
  VARIANT:=wpad-basic

wpad-mesh-openssl
  [identical part removed]
  DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
  PROVIDES+=wpa-supplicant-mesh wpad-mesh
  DEPENDS+=+libopenssl
  VARIANT:=wpad-mesh-openssl

wpad-mesh-wolfssl
  [identical part removed]
  DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
  PROVIDES+=wpa-supplicant-mesh wpad-mesh
  DEPENDS+=+libwolfssl
  VARIANT:=wpad-mesh-wolfssl

This looks like a bug in some of the Config.in files used by make menuconfig.
Just to support this, I exchanged the order in which wpad-mesh-openssl and wpad-mesh-wolfssl are defined in tmp/.config-package.in and now wpad-mesh-wolfssl and wpad-mesh-openssl are at the same hierarchical level. Makes no sense.

[ilario]

The report on OpenWrt side is here: https://bugs.openwrt.org/index.php?do=details&task_id=3441

[ilario]

Additional scenario that makes this issue more annoying:

1. open menuconfig
2. select wpad-mesh-wolfssl and deselect wpad-basic
3. close and save
4. my .config is like this: http://sprunge.us/3fE1sU
5. open menuconfig
6. close and save
7. my .config changed and wpad-mesh-wolfssl is not selected anymore, see it here: http://sprunge.us/FGQgeY

This means that every time I modify something in the menuconfig, I have to select again the wpad-mesh-wolfssl package.

@aparcar @spiccinini @dangowrt any insight?

[AndyMcSchopf]

Hey Ilario I can confirm this, had the same struggle but didn't look deeper into that. Thanks for addressing this to OpenWRT Team!

[ilario]

I looked into this and is caused by how the conflicting packages lists are defined, incrementally across the Makefile.
Here the full comment: https://bugs.openwrt.org/index.php?do=details&task_id=3441#comments

[ilario]

In short what happens is that the definition of two variables is evolving through the Makefile (as implemented in openwrt/openwrt@3838b16 by @mkresin) and this creates an asymmetry that ends up in the menuconfig misbehaviour.

$HOSTAPD_PROVIDERS inside wpad-mesh-openssl is hostapd hostapd-basic hostapd-mini hostapd-openssl hostapd-wolfssl wpad

$HOSTAPD_PROVIDERS inside wpad-mesh-wolfssl is hostapd hostapd-basic hostapd-mini hostapd-openssl hostapd-wolfssl wpad wpad-mesh-openssl

$SUPPLICANT_PROVIDERS inside wpad-mesh-openssl is wpad

$SUPPLICANT_PROVIDERS inside wpad-mesh-wolfssl is wpad wpad-mesh-openssl

@mkresin @nbd168 do you think it's possible to find another way to solve the "conflicts hell"?

[ilario]

Another message revealing this issue: menuconfig says:

tmp/.config-package.in:139918:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:139918:	symbol PACKAGE_wpad-mesh-wolfssl is selected by PACKAGE_wpad-mesh-wolfssl

ping @mkresin @nbd168

I agree that the current solution is clean but does not work well enough, so an alternative I can think of is defining a list of all the "providers" and then using CONFLICTS:=$(filter-out package_name, $(providers_list)).
This is similar to the "conflicts hell" situation before @mkresin but I cannot find a different solution.