Proposal: Refactor image configuration JSON for maintainability and reduced redundancy

[hanthor]

Context

The current images.json used by the installer has grown significantly as we’ve added more flavors and version tracks (Fedora 42/43, NVIDIA vs. Open, etc.). The file currently contains heavy duplication of registry paths, Flatpak Brewfile URLs, and repetitive metadata.

The Problem

• Redundancy: Registry namespaces like ghcr.io/ublue-os/ and ghcr.io/tuna-os/ are hardcoded hundreds of times.
• Maintenance Overhead: Updating a single URL (like a shared Brewfile) or incrementing a Fedora version requires dozens of find-and-replace operations.
• Complexity: The deep nesting makes it difficult to see the relationship between different "flavors" (e.g., Bazzite GNOME vs. Bazzite KDE).

Proposed Solutions

1. Implement Registry & Namespace Templating

Instead of full imgref strings, we should define a registry_base or namespace at the parent level. Children can then just specify the tag or a suffix.

• Benefit: Reduces the string size of the JSON and makes migrating registries a single-line change.

2. Define Global Aliases for Remote Assets

Commonly reused URLs, such as the shared Flatpak Brewfiles for Bluefin or Aurora, should be moved to a root-level refs or aliases object.

• Example: Use @bluefin_flatpaks instead of the full GitHub raw URL in every image entry.

3. Transition to a "Flavor Matrix" for Bazzite/TunaOS

For images with high variance (Desktop Environment × GPU Driver × Kernel), we should move away from literal deep-nesting. By defining "flavors" and "modifiers" once, the installer logic can construct the final image reference dynamically.

4. Metadata Inheritance

Many children share identical desc or search_extra tags. We should implement a fallback mechanism where a child inherits the parent's metadata unless explicitly overridden.

Example Refactored Structure (Concept)

{
  "aliases": {
    "ublue_brew": "https://raw.githubusercontent.com/ublue-os/..."
  },
  "images": [
    {
      "name": "Aurora",
      "registry": "ghcr.io/ublue-os/aurora",
      "flatpaks": "@ublue_brew",
      "children": [
        { "name": "Stable", "tag": "stable" },
        { "name": "Fedora 43", "tag": "43" },
        { 
          "name": "Aurora DX", 
          "registry": "ghcr.io/ublue-os/aurora-dx", 
          "inherit": true 
        }
      ]
    }
  ]
}

Next Steps

1. Verify if the current parser can be updated to handle variable substitution (the @ or {{tag}} syntax).
2. Identify which "modifiers" (NVIDIA, HWE, etc.) are consistent across all TunaOS/Bazzite images to standardize the matrix.
3. Draft a schema update to support these inheritance rules.
   I'm happy to put together a PR for the logic side if we agree this is the right direction for the schema.