search

libremesh / lime-packages

LibreMesh packages configuring OpenWrt for wireless mesh networking
https://libremesh.org/
GNU Affero General Public License v3.0
277 stars 96 forks source link

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

Open ilario opened 4 years ago

ilario commented 4 years ago

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.

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/libremesh/lime-packages/pull/729#discussion_r479648654, and that in an idyllic future should get upstreamed) there's a negative opinion here: https://github.com/libremesh/lime-packages/pull/729#issuecomment-654471103 with which I neither agree nor disagree.

dangowrt commented 4 years ago

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 commented 4 years ago

... 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ilario commented 3 years ago

Mitigated (not fixed!) in #775

ilario commented 3 years ago

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

spiccinini commented 3 years ago

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