Migrate all LibreMesh-related packages' Makefile to libremesh.mk new format

[ilario]

On #729 a new format for the Makefile of LibreMesh packages has been proposed.
Here is a list of the packages which depends on lime-system package and which would be good to migrate to the new format.
It could be possible that for some of these packages the migration is not possible, please check each case.

• lime-proto-babeld Use libremesh.mk #729
• lime-proto-batadv Use libremesh.mk #729
• lime-proto-bmx6 Use libremesh.mk #729
• lime-proto-bmx7 Use libremesh.mk #729
• lime-proto-wan Use libremesh.mk #729
• lime-smart-wifi Use libremesh.mk #729
• deferable-reboot
• lime-hwd-ground-routing
• lime-hwd-openwrt-wan
• lime-hwd-usbradio
• lime-proto-anygw
• lime-proto-bgp
• lime-proto-olsr2
• lime-proto-olsr6
• lime-proto-olsr
• lime-webui
• safe-upgrade
• ubus-lime-batman-adv
• ubus-lime-bmx6
• wifi-unstuck-wa

Additionally, there are packages with lime in their name but which suspiciously do not explicitly depend on lime-system, these also should be checked and maybe migrated also:

lime-app
lime-ap-watchping
lime-debug (metapackage, do not require lime-system)
lime-docs (just docs, do not require lime-system)
lime-map-agent
lime-report (works also without LibreMesh stuff)
luci-app-lime-location
ubus-lime-fbw
ubus-lime-groundrouting
ubus-lime-location
ubus-lime-metrics
ubus-lime-openairview
ubus-lime-utils

[dangowrt]

Why only use libremesh.mk for packages which depend on lime-system? I thought it was mostly to automate versioning (like for luci-* packages)...?

[ilario]

Why only use libremesh.mk for packages which depend on lime-system?

I'm not sure I got the question, but I try to answer: inside libremesh.mk there is a hardcoded dependency on lime-system.

I think that we should add also another .mk file identical but without lime-system dependency (what should be the filename?) to be used in the aforementioned packages: the LibreMesh-specific but not depending on lime-system.

Regarding the non-LibreMesh-specific packages that are still hosted here (which are many, see #729 (comment), and that in an idyllic future should get upstreamed) there's a negative opinion here: #729 (comment) with which I neither agree nor disagree.

[dangowrt]

Why only use libremesh.mk for packages which depend on lime-system?

I'm not sure I got the question, but I try to answer: inside libremesh.mk there is a hardcoded dependency on lime-system.

I think that we should add also another .mk file identical but without lime-system dependency (what should be the filename?) to be used in the aforementioned packages: the LibreMesh-specific but not depending on lime-system.

... or just add the dependency individually to the packages which actually require it. Having the dependency on lime-system outsourced to libremesh.mk is a minor advantage compared to automated versioning based on the repository.

Regarding the non-LibreMesh-specific packages that are still hosted here (which are many, see #729 (comment), and that in an idyllic future should get upstreamed) there's a negative opinion here: #729 (comment) with which I neither agree nor disagree.

[ilario]

... or just add the dependency individually to the packages which actually require it. Having the dependency on lime-system outsourced to libremesh.mk is a minor advantage compared to automated versioning based on the repository.

Ok, makes sense. I'm going to edit the issue title.

What do you think about the "upstreamable material" non related to LibreMesh mentioned above?
Is it better to leave the original Makefile or to unify also theirs?

[spiccinini]

Some packages depend only in the lime.utils part of lime-system package. In my opinion we should refactor out this lua module into its own package.

[ilario]

Some packages depend only in the lime.utils part of lime-system package. In my opinion we should refactor out this lua module into its own package.

To add some data, here you are a table of the required lua files from lime-system by each package:

Package	Required lua file
deferable-reboot	lime.config lime.utils
first-boot-wizard	lime.config lime.utils lime.wireless
lime-hwd-ground-routing	lime.config lime.hardware_detection lime.utils
lime-hwd-openwrt-wan	lime.config lime.hardware_detection lime.network lime.hwd.openwrt_wan lime.utils
lime-hwd-usbradio	lime.config lime.hardware_detection lime.utils
lime-proto-anygw	lime.config lime.network lime.system
lime-proto-babeld	lime.config lime.network
lime-proto-batadv	lime.config lime.network lime.proto lime.utils lime.wireless
lime-proto-bgp	lime.config lime.network lime.utils
lime-proto-bmx6	lime.config lime.network lime.utils lime.wireless
lime-proto-bmx7	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr2	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr6	lime.config ime.network lime.utils lime.wireless
lime-proto-wan	lime.utils
lime-smart-wifi	lime.config lime.utils lime.wireless
lime-system	lime.config lime.generic_config lime.mode lime.network lime.system lime.utils lime.wireless
lime-webui	lime.config
safe-upgrade	lime.utils
shared-state	lime.utils lime.wireless
ubus-lime-batman-adv	lime.utils
ubus-lime-bmx6	lime.utils
ubus-lime-groundrouting	lime.config lime.network
ubus-lime-location	lime.config lime.network lime.utils lime.wireless
ubus-lime-metrics	lime.utils
ubus-lime-openairview	lime.utils
ubus-lime-utils	lime.config lime.wireless lime.utils
wifi-unstuck-wa	lime.config lime.utils

There are 6 packages depending only from lime-system, still I do not agree with @spiccinini: to me it seems that all of these 6 packages are LibreMesh-specific ones, that make little sense in an installation without lime-system. Do you agree?

Another interesting, but unrelated, info that can be obtained from the table is that shared-state should also depend on lime-system, and that if we want to push it upstream we will have to change this.

[ilario]

Maybe I misunderstood @spiccinini proposal: are you proposing to make lime.utils a non-LibreMesh-related package which could end up in OpenWrt repositories?
In order to do this we should remove the usage of lime.config inside lime.utils.

[spiccinini]

Maybe I misunderstood @spiccinini proposal: are you proposing to make lime.utils a non-LibreMesh-related package which could end up in OpenWrt repositories?
In order to do this we should remove the usage of lime.config inside lime.utils.

Yes, I think that it would be good to have part of the functionality that does not depend on the "lime" concept. And you are right about lime.config that it is in the middle. Some part of the fuctionality of lime.config is very handy outside libremesh too (the part that allows to make unittests with configs for example).
I know that at least in LuCi they are moving to javascript. I don't know about other openwrt related projects. Anyway in my opinion the only sane scripting language for openwrt remains to be lua. I don't know how valuable is for other projects to do this spliting.

[ilario]

I created a new issue for following this lime-utils thing :)

[ilario]

Mitigated (not fixed!) in #775

[ilario]

Now that the release is out, can we migrate the packages' Makefiles to use libremesh.mk?

[spiccinini]

I've opened #829 with the intention to have a middle ground that can be used in all makefiles.