Better OpenWrt support

[aparcar]

Hi, I'm an OpenWrt developer and was wondering if the following format would help repology to parse packages? Right now multiple fields are missing and the website even mentions "removal" of the index, due to poor formatting.

https://gist.github.com/aparcar/0eeaa45ff99f20330bda7df26ff5c581

{
  "packages": [
    {
      "name": "base-files",
      "version": "1654~4b6886d9fd",
      "hashes": "e1e5af18044110c9b9ef2044b05600aef457a6ef945d62bd258035181673b8f6",
      "description": "This package contains a base filesystem and system scripts for OpenWrt.",
      "arch": "aarch64_generic",
      "license": "GPL-2.0",
      "origin": "feeds/base/base-files",
      "url": "http://openwrt.org/",
      "installed-size": 483328,
      "file-size": 56836,
      "depends": [
        "busybox",
        "fstools",
        "fwtool",
        "jsonfilter",
        "libc",
        "netifd",
        "openwrt-keyring",
        "procd",
        "procd-seccomp",
        "usign"
      ]
    },
...

If so, I'll see to offer these files on a daily basis on our official servers.

[AMDmi3]

It's ok as basically any json format would be. The current problems with openwrt are not really related to the format, so we may want to focus on these if we want to improve the support. Here's what I see having given a quick glance at the code:

• Lack of upstream links (I see these are present in the new format which is great)
• Flapping packages in snapshot, can this be addressed (since snapshot support would probably be the most useful for maintainers as it shows currently packaged versions)?
• Inconsistent module naming

Some issues may no longer be actual though.

[aparcar]

• Lack: We'll be adding more fields but even in the old JSON should already be the URL available, I added a PR
  • Parse URL/CPE-ID from OpenWrt packages #1474
• Flapping: Our packages sometimes fail to build but should be back in the next cycle, Is it a problem for repology if those packages "come and go"?
• Module naming: I can see to talk to maintainers but this will take time to migrate over, is this a hard blocker to become "supported"?

[AMDmi3]

Lack: We'll be adding more fields but even in the old JSON

Debian-like format, you mean?

should already be the URL available, I added a PR

Thanks, added a note there.

Flapping: Our packages sometimes fail to build but should be back in the next cycle, Is it a problem for repology if those packages "come and go"?

Of course. Package metadata should not depend on the instant build status (however it would be nice to have permanently broken packages removed or marked).

Module naming: I can see to talk to maintainers but this will take time to migrate over, is this a hard blocker to become "supported"?

It is supported. It just could be improved. I'd say you shouldn't disturb maintainers until I properly review the status. The inconsistency claim is quite old and may no longer be actual. For instance, I don't see a problem with modules mentioned in the code comment on recent OpenWRT releases.

Some other problems should be visible here though. These are not critical for Repology as these have known patterns which can just be ignored, but these prevent proper status reporting for affected openwrt packages and could be improved by e.g. basing snapshot versions on latest upstream release (e.g. hostaptd 2.11-2023-09-08-e5ccbfc6 instead of 2023-09-08-e5ccbfc6) and not prefixing perl module versions.