Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
6 of 20 tasks
ilario opened this issue Sep 28, 2020 · 12 comments
Open
6 of 20 tasks

Comments

@ilario
Copy link
Member

ilario commented Sep 28, 2020

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
Copy link
Member

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
Copy link
Member Author

ilario commented Sep 28, 2020

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
Copy link
Member

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
Copy link
Member Author

ilario commented Sep 29, 2020

... 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?

@ilario ilario changed the title Migrate LibreMesh-specific packages' Makefile to libremesh.mk new format Migrate all LibreMesh-related packages' Makefile to libremesh.mk new format and de-hardcode the dependency from lime-system Sep 29, 2020
@spiccinini
Copy link
Contributor

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
Copy link
Member Author

ilario commented Oct 2, 2020

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
Copy link
Member Author

ilario commented Oct 2, 2020

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
Copy link
Contributor

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
Copy link
Member Author

ilario commented Oct 3, 2020

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

@ilario
Copy link
Member Author

ilario commented Oct 12, 2020

Mitigated (not fixed!) in #775

@ilario ilario changed the title Migrate all LibreMesh-related packages' Makefile to libremesh.mk new format and de-hardcode the dependency from lime-system Migrate all LibreMesh-related packages' Makefile to libremesh.mk new format Oct 15, 2020
@ilario
Copy link
Member Author

ilario commented Dec 15, 2020

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

@spiccinini
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants