-
Notifications
You must be signed in to change notification settings - Fork 96
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
Comments
Why only use |
I'm not sure I got the question, but I try to answer: inside I think that we should add also another .mk file identical but without 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. |
... 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? |
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:
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. |
Maybe I misunderstood @spiccinini proposal: are you proposing to make lime.utils a non-LibreMesh-related package which could end up in OpenWrt repositories? |
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 created a new issue for following this lime-utils thing :) |
Mitigated (not fixed!) in #775 |
Now that the release is out, can we migrate the packages' Makefiles to use libremesh.mk? |
I've opened #829 with the intention to have a middle ground that can be used in all makefiles. |
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 onlime-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
The text was updated successfully, but these errors were encountered: