cascade of metapackages kills modularity

[dangowrt]

I'm trying to use lime with something else than the usual combination of bmx6+batman-adv.
However, this is currently nearly impossible because of a cascade of meta-packages which pull-in a lot of packages via their dependencies. I tried crafting a flavor with bmx7-only and failed because the current approach of meta-packages and flavors was left behind in the past when we were still always building everything from source. When using the ImageBuilder, things like

DEPENDS:=+PACKAGE_lime-proto-bmx6:luci-app-bmx6

won't work because CONFIG_PACKAGE_lime-proto-bmx6=m no matter if the user actually intended to use bmx6 at all.

Hence I suggest to entirely drop all optional things from the lime-basic, lime-full, lime-mini, lime-webui, ... packages. Those packages can then be pulled in via the dependencies of a community-profile-package of a community which makes use of them. In that way, modularity can be restored and selecting lime-basic or lime-webui won't automatically pull-in potentially unwanted packages.
I'm not only talking about routing protocols and autogw stuff, but also things like lime-hwd-openwrt-wan which I went through difficult loops only in order to finally get rid of it.

What do you think?
@aparcar @p4u @nicoechaniz @altergui @G10h4ck

If you agree, I'll start working on a PR to remove all protocol-specific or somehow optional dependencies from the meta-packages.

[dangowrt]

Another example: In flavors.conf, many of the flavors remove dnsmasq. But lime-basic then pulls in dnsmasq-lease-share and dnsmasq-distributed-hosts which doesn't make sense without dnsmasq...

[ilario]

On removing unnecessary dependencies from collections: +1
(in my opinion lime-sdk flavors obsoletes lime-full-* collections)
As a related issue see #175

---

The example you cited is a conditional dependency, do we want to remove them? They were useful when the recommended compilation method was OpenWrt buildroot and menuconfig, now they're just annoying.

List of conditional dependencies in this repository:

lime-debug:		+PACKAGE_lime-proto-batadv:batctl
lime-map-agent:	+PACKAGE_lime-proto-bmx6:luci-lib-libremap-bmx6
lime-proto-anygw:	@(!PACKAGE_dnsmasq)
lime-proto-bmx6:	+!PACKAGE_firewall:iptables
lime-proto-bmx7:	+!PACKAGE_firewall:iptables
lime-proto-wan:	+!PACKAGE_firewall:iptables
lime-webui:		+PACKAGE_lime-proto-bmx6:luci-app-bmx6
lime-webui:		+PACKAGE_lime-proto-batadv:luci-app-batman-adv

[aparcar]

@dangowrt If you find the time, I'd be happiest to see such a PR

PS: As I'm also working on a bmx7 setup, here a tasty flavor

bmx7="lime-system lime-hwd-openwrt-wan bmx7 bmx7-auto-gw-mode lime-proto-wan lime-proto-bmx7 luci bmx7-iwinfo"

[p4u]

Hi @dangowrt

I understand your concerns, but (as you already pointed) collections where created mainly to be used in BuildRoot and not in ImageBuilders. IMO it's still useful for those who want to use BuildRoot (which is one of the ways to build your own firmware) to have the collections available and conditional dependencies.

However with "cooker" or ImageBuilder it might not make sense to use collections. So instead specify all required packages (starting from the most basic lime-system).

I'm also deploying a mesh network with only bmx7, this is my flavor in cooker.

lime_bmx7="lime-system lime-proto-bmx7 luci-app-bmx7 lime-proto-wan lime-hwd-openwrt-wan bmx7-auto-gw-mode smonit luci-mod-admin-full lime-debug dnsmasq"

I agree that we should probably have more flavors in cooker and get rid of collections (lime-full, lime-basic, lime-webui).

However, if you have in mind a better solution that might solve both cases (in BuildRoot user should be able to select just a collection and that makes all the work), I'm very open to hear it.

Another example: In flavors.conf, many of the flavors remove dnsmasq. But lime-basic then pulls in dnsmasq-lease-share and dnsmasq-distributed-hosts which doesn't make sense without dnsmasq...

Cause lime-full depends on lime-proto-anygw which depends on dnsmasq-dhcpv6, so it makes sense to remove dnsmasq (not needed) cause dnsmasq-dhcpv6 is selected.

[FreifunkUFO]

hi @dangowrt . there is also a possibility to deleselect packages to modify meta-package-selections.
near "lime-hwd-openwrt-wan" discussion there were some more issue-tickets, but all got closed.
libremesh/chef#8
libremesh/network-profiles@5ab8abf
libremesh/network-profiles#13

[nicopace]

How do we proceed with this?
Can we close it?
more than 30 days without update here.

[aparcar]

I think @dangowrt should reply first

[dangowrt]

We haven't concluded on a way to handle this. For now I got a dirty local patches to simply remove all conditional dependencies and that works for me. But I beleieve it is an issue which should be adressed upstream because I'd rather want to use chef-built images.
In a way, the problem are really just the dependencies of lime-webui and lime-map-agent, because all other packages with conditional dependencies are either pure meta-packages or got conditionals which are meaningless for non-buildroot-from-scratch builds (such as the dependency on iptables if firewall is not selected during build time)