image-customization: add is_cellular_device and is_outdoor_device

[maurerle]

It would be quite handy to be able to call:
is_cellular_device and is_outdoor_device from platform.lua in the image-customization.lua

gluon/package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

Line 25 in 9a8ee57

function M.is_outdoor_device()

Originally posted by @maurerle in #3054 (comment)

This might be handled by one of the following:

1. from the openwrt json source
2. by extracting the list of devices from platform.lua to something more dynamic (like a separate json file)
3. by extracting the two functions into a separate lua file which can also be imported by image-customization-lib

What is the preferred way to tackle this in the future @blocktrron?

[blocktrron]

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?

[maurerle]

We currently do have maintained lists of cellular and outdoor routers in gluon-core:

https://github.com/freifunk-gluon/gluon/blob/9a8ee5733365c0a64531c539a578133bbc6429ac/package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

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

[blocktrron]

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