Open maurerle opened 1 month ago
I see there's an interest in aggregating selection criterias for this in Gluon.
I don't like the idea in maintaining such a list in the main repository. This is due to decision making based on small amount of people, and the expectation this gets actively maintained.
I see the community-packages as a good example to establish a middle ground for this. What about creating a repository communities can reference which provides selection criteria and is maintained by the community self-governing?
We currently do have maintained lists of cellular and outdoor routers in gluon-core:
And I do not see this going away soon? There is a quite good process of maintaining the list as both checks are a part of the device integration checklist.
That said, I would not have a problem of maintaining such lists downstream in a community-maintained repository - as this could then also contain has_usb
and other things which were requested by @grische in #3143.
Then we would only need to have #3148 merged and backported to create a snippet which can be included right? :blush:
@maurerle We have the list for runtime functionality, however we can not use them as-is at build-time, so they do not relate in the use-case you are describing.
There was a case made by @grische to select based on RAM / flash-size. Handling both by extracting selectors out of gluon for the image-customization is a long-term solution for all sorts of selection criteria. That being said, providing some kind of universal (extensible) selection mechanic which we can call at run-time as well as build-time is preferred, yes.
It would be quite handy to be able to call:
is_cellular_device
andis_outdoor_device
from platform.lua in the image-customization.lua https://github.com/freifunk-gluon/gluon/blob/9a8ee5733365c0a64531c539a578133bbc6429ac/package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua#L25Originally posted by @maurerle in https://github.com/freifunk-gluon/gluon/issues/3054#issuecomment-1865847226
This might be handled by one of the following:
What is the preferred way to tackle this in the future @blocktrron?