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:

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

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