[quote="hnyman, post:2, topic:123, full:true"]I highly doubt that an automatic long list / database of all available packages would be useful for newcomers.[/quote]The ToH's database system main use is making many tables (called "views") where the content of the same large database is already filtered heavily to show only X or only Y.
The monstrously huge table is mostly for mantainers or people testing their massive multiscreen setup.
If you want to make a table in a wiki article showing only USB, basic routing, whatever, you write like 5 lines to summon the data plugin and tell it what you need there, and the plugin does the leg work in reading the database, fetching the right information according to your filters and showing it.
And this is kept updated automatically, you just update the central database, and every other table downstream will be up-to-date.
[quote]There are thousands of packages/variants/modules, many of which have only short and non-descriptive titles & descriptions, while others have long "advertising-style" descriptions. So, the data that can be automatically collected, would be non-uniform.[/quote]Having a way to show package descriptions like that will encourage better descriptions from the package mantainer, and normal people might start sending "improved description" PRs through Github's webinterface.
[quote]The availability of the packages varies somewhat by the architecture/platform, which also causes complexity to the possible database/script.[/quote]Architecture would just be another field in the database (shown or not depending on need, surely used for filters).
It might be necessary to read the makefiles in the source instead than the actually downloadable package lists to get that info faster, though. (I assume that if it works for the build system it will work for a script loading a database too)
[quote]Page could be something like "Extend the device's functionalities with add-on packages". It could have maybe 20-50 categories (USB storage, statistics, web proxy, adblocking, VPN, QoS, P2P, USB modems, file server, home media server, multimedia etc.) and each category could have a link to a possible "How-to" recipe/topic page of that topic (if such page exists) and a list of 1-5 most widely used / most useful packages for that topic. [/quote]Yes, I was thinking about making something like this, with different pages for different categories. Just that the tables in the articles would be auto-generated according to my filters.
Having the packages in a database would allow also to automate the "most used" selection. Just add a field in the database to mark the package as "most-used" and you can auto-build and maintain tables with only "most-used" packages, reducing the need for manual editing.
The same can be done to packages "marked-for-deletion", or "from-a-third-party-repo" or "LEDE-trunk" or "LEDE-first-release-branch" or "LEDE-second-release-branch" or for whatever reason.
The goal is to get something like most PC Linux distros have, like for example Debian, https://packages.debian.org/stable/
(Debian has a relatively simple system with large lists of packages, but you should note the basic features of a webpage showing packages)