[OpenWrt-Devel] mac80211: Add dependency on ip (iproute2) to cfg80211

Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
a client association. 'ip' is not automatically included with cfg80211
custom builds -- association fails.

Signed-off-by: Ted Hess <thess@kitschensync.net>
---
 package/kernel/mac80211/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 2015-11-16 20:28, Ted Hess wrote:
> Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
> a client association. 'ip' is not automatically included with cfg80211
> custom builds -- association fails.
> 
> Signed-off-by: Ted Hess <thess@kitschensync.net>
NACK. These changes were added because the busybox ip applet was enabled
by default recently.

- Felix

On 16 November 2015 at 23:40, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2015-11-16 20:28, Ted Hess wrote:
>> Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
>> a client association. 'ip' is not automatically included with cfg80211
>> custom builds -- association fails.
>>
>> Signed-off-by: Ted Hess <thess@kitschensync.net>
> NACK. These changes were added because the busybox ip applet was enabled
> by default recently.

So there is a dependency (ip package OR ip support in Busybox), but no
way to express it?

Not that it would make sense for anybody to disable the new default in
busybox without enabling the ip package at the same time. Just
curious.

Is there a way to add "provides" to a package? In RPM, I would solve this
adding "Provides: ip" to busybox.

This could also help when a kern module gets built-in. Kernel package could
provide the incorporated kmod-xxx module. It would be better if both kernel
and kmod-xxx could automatically provide every single module it provides,
so packages could requires modules and not their packages, whether it is
built-in or loadable module.

Just like the case of busybox, if someone changes a module to not be
built-in (a configuration), it will require a code (makefile) change in
order to fix broken deps.

Luiz

Em ter, 17 de nov de 2015 06:11, Cristian Morales Vega <
cristian@samknows.com> escreveu:

> On 16 November 2015 at 23:40, Felix Fietkau <nbd@openwrt.org> wrote:
> > On 2015-11-16 20:28, Ted Hess wrote:
> >> Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
> >> a client association. 'ip' is not automatically included with cfg80211
> >> custom builds -- association fails.
> >>
> >> Signed-off-by: Ted Hess <thess@kitschensync.net>
> > NACK. These changes were added because the busybox ip applet was enabled
> > by default recently.
>
> So there is a dependency (ip package OR ip support in Busybox), but no
> way to express it?
>
> Not that it would make sense for anybody to disable the new default in
> busybox without enabling the ip package at the same time. Just
> curious.
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>

On 2015-11-17 12:59, Luiz Angelo Daros de Luca wrote:
> Is there a way to add "provides" to a package? In RPM, I would solve
> this adding "Provides: ip" to busybox.
> 
> This could also help when a kern module gets built-in. Kernel package
> could provide the incorporated kmod-xxx module. It would be better if
> both kernel and kmod-xxx could automatically provide every single module
> it provides, so packages could requires modules and not their packages,
> whether it is built-in or loadable module.
> 
> Just like the case of busybox, if someone changes a module to not be
> built-in (a configuration), it will require a code (makefile) change in
> order to fix broken deps.
I personally think changing package metadata for this this is a waste of
time. There are so many different ways in which you can screw up a build
by customizing the busybox configuration, and it would be a futile
effort to try to add checks for them all.

People that customize their busybox config should just check the output
of ./scripts/diffconfig.sh for any missing options if they run into any
issues. Problematic changes are typically very easily visible there,
since the output contains very few items aside from changes directly
made by the user or options that went out of sync with the default
configuration.

- Felix