Hi Adrian,
On 25.03.2020 16:53, [email protected] wrote:
-----Original Message-----
From: Piotr Dymacz [mailto:[email protected]]
Sent: Mittwoch, 25. März 2020 15:08
To: [email protected]; [email protected]
Cc: Felix Fietkau <[email protected]>; Jo-Philipp Wich <[email protected]>
Subject: Re: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default
with any wpad variant
Hi Adrian,
On 25.03.2020 12:21, [email protected] wrote:
> Hi Piotr,
>
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-
[email protected]]
>> On Behalf Of Piotr Dymacz
>> Sent: Mittwoch, 25. März 2020 00:34
>> To: [email protected]
>> Subject: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default
>> with any wpad variant
[...]
> Since you are touching this, maybe you can elaborate why this
> extra_packages construct is needed at all?
I don't know exact reason and it was added long time ago, in 2014, see:
6435b8bb27e. I suppose that was the easy way to handle it back then?
> Why can't we just add iwinfo as selective dependency to the wpad-/nas
> packages as we do for all of the other packages?
Could you explain what you mean by 'selective dependency'?
I don't think DEPENDS is correct way to handle this. Do you mean use 'select
iwinfo' in wpad/nas packages config?
From the point of _functionality_, it would just be a
DEPENDS := +iwinfo
for the relevant packages.
However, I'm aware that this is not correct from a _conceptional_ point of view, since
iwinfo is not a "dependency".
Exactly, plus this has also run-time consequences.
> I'm asking because I recently had a downstream case where we use
> hostapd instead of wpad and wanted to get of iwinfo. I expected iwinfo
> to go away because nothing selected it anymore, but in this case it
> turned out that iwinfo is not automatically deselected, but has to be
> removed manually as well.
I suppose you should first look at DEFAULT_PACKAGES and target.mk.
In most cases, wpad-* is added there and that's how iwinfo gets selected.
For tiny devices, we replace wpad-mini by hostapd-mini (ar71xx/ath79):
CONFIG_PACKAGE_hostapd-mini=y
CONFIG_PACKAGE_wpad-mini=m
However, this will not unselect iwinfo (as it should theoretically according to the
extra_packages condition), which will still be at "y", so will be built into
the images.
This can also be observed in make menuconfig, where deselecting any wpad packages does not affect
the status of iwinfo. I assume that the extra-packages condition is just evaluated "too
early", and not updated during evaluation in make menuconfig like "real"
dependencies.
Of course, removing iwinfo/libiwinfo from images can easily be achieved by
CONFIG_PACKAGE_iwinfo=m
CONFIG_PACKAGE_libiwinfo=m
It's just not a "live-update" like we are used to from DEPENDS.
If you are using custom config files for building, this is the correct
way to handle it.
From looking at the dependencies as described in the Wiki [1], I do not think
there really is an alternate solution available at the moment, though.
Are you sure (warn: haven't tried that)?
https://openwrt.org/docs/guide-developer/dependencies#special_notes
Somebody would have to build one, something like @TARGET_ath79, but not for visibility,
but for selection. So, somebody could just add the new "dependency" (using § as
symbol for the example) to the iwinfo package instead of using the extra_packages
construct:
DEPENDS += §wpad-mini §wpad-basic §nas ...
However, I'm not sure whether implementing that would really be worth it,
considering that disabling extra_packages manually is still quite easy to do.
No.
This is not a dependency so DEPENDS is not the correct way to handle it.
--
Cheers,
Piotr
Best
Adrian
[1] https://openwrt.org/docs/guide-developer/packages#dependency_types
But I see the problem here, I'm just not sure if it's safe to change current
approach. Maybe Felix or Jo are able to explain reason for using
extra_packages.
--
Cheers,
Piotr
>
> Best
>
> Adrian
>
>>
>> define ProfileDefault
>> NAME:=
>> --
>> 2.20.1
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> [email protected]
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
