🚀 Feature Proposal: Archinstall ↔ Archiso Deep Integration (Calamares-level Customization)

[guidryheal-create]

describe the request

🧠 Summary

The goal is to bring Calamares-level customization and UX to archinstall, by tightly integrating it with archiso.

Instead of manually defining installation configs or hardcoding menus, the installer should:

• Auto-detect the running ISO environment
• Extract configuration from archiso build artifacts
• Generate a full archinstall config dynamically
• Provide a customizable TUI experience driven by metadata (not hardcoded menus)

---

🎯 Objectives

1. 🔍 Auto-detect ISO Configuration

When running inside an archiso environment, archinstall should automatically detect:

• packages.x86_64
• Installed kernel(s)
• Enabled services
• Preinstalled applications
• Default user/session config
• Live environment behavior (e.g. Plasma, GNOME, minimal, etc.)

👉 This allows the installer to mirror the live ISO setup into the installed system.

---

2. 🧩 Dynamic Config Generation

Instead of requiring a static JSON config, archinstall should:

• Generate a full installation config automatically from:

  • ISO metadata
  • System state
  • Optional user input (TUI)

Example:

• Detect KDE Plasma → auto-fill profile_config
• Detect PipeWire → auto-fill audio_config
• Detect kernel → auto-fill kernels
• Detect services → auto-fill services

👉 Result: zero-config install baseline, modifiable via TUI.

---

3. 🧱 Archiso Metadata Layer

Extend archiso to expose structured metadata for the installer.

Proposed additions:

• /etc/archiso/installer.json (or similar)

• Declarative definitions for:

  • Profiles
  • Applications
  • Services
  • Branding
  • Default behaviors

Example:

{
  "profile": "kde",
  "applications": ["firefox", "konsole"],
  "services": ["sddm", "NetworkManager"],
  "kernel": "linux-zen",
  "branding": {
    "name": "MyDistro",
    "logo": "/usr/share/mydistro/logo.png"
  }
}

👉 archinstall consumes this and builds menus + config dynamically.

---

4. 🧠 Meta-driven TUI (No Hardcoded Menus)

Replace static menu definitions with auto-generated menus:

• Discover available modules (apps, profiles, services)

• Use class metadata / tags to decide:

  • Visibility
  • Category
  • Menu placement

Example concept:

class KDEProfile(Profile):
    __archinstall_meta__ = {
        "category": "desktop",
        "name": "KDE Plasma",
        "default": True
    }

👉 The TUI builds itself from available modules.

---

5. 🎨 Full Branding & Custom Installer UX

Allow archiso builders to define:

• Custom TUI layout
• Custom steps / workflow
• Branding (name, colors, ASCII/logo)
• Predefined flows (minimal / advanced / OEM / gaming distro)

👉 This enables:

• Distro-like installers without rewriting archinstall
• OEM installers
• Opinionated setups (Hyprland ISO, Dev ISO, etc.)

---

6. 🔄 Persistence-aware Installation

Use archiso context to:

• Detect persistence setup (if any)

• Offer migration of live environment → installed system

• Reuse:

  • User configs
  • Installed packages
  • Session state

👉 Makes live ISO → installed system feel seamless.

---

7. ⚙️ Generalized Installer Pipeline

Abstract installer steps into modular stages:

• disk
• base system
• kernel
• services
• applications
• profiles
• post-install hooks

Each stage:

• Can be extended
• Can be overridden by archiso metadata
• Can be toggled via TUI

---

🧩 Proposed Architecture

archiso
 ├── packages.x86_64
 ├── profiledef.sh
 ├── installer.json   <-- new
 └── live environment
        ↓
archinstall
 ├── detect ISO context
 ├── parse metadata
 ├── scan modules (profiles/apps)
 ├── build dynamic TUI
 ├── generate config
 └── run installer pipeline

---

✅ Benefits

• 🔥 Near Calamares-level UX, but fully scriptable
• 🧩 No need to fork archinstall for custom ISOs
• ⚡ Zero-config installs possible
• 🎯 Consistency between live ISO and installed system
• 🛠 Easier to build custom Arch-based distros
• 🧠 Cleaner architecture (data-driven, not hardcoded)

---

⚠️ Challenges / Considerations

• Backward compatibility with existing configs

• Security (executing ISO-provided metadata)

• Standardizing metadata format

• Avoiding over-complexity in TUI generation

• Clear separation between:

  • detection
  • config generation
  • execution

---

💡 Future Extensions

• Plugin system for profiles/apps
• Remote config sources (URL-based installs)
• GUI frontend reusing same backend (like Calamares)
• Declarative installer pipelines

---

🧪 MVP Scope

Start small:

1. Detect archiso environment
2. Parse a simple installer.json
3. Auto-fill archinstall config
4. Minimal dynamic menu (profiles + apps)

---

🧭 Closing Thought

This would effectively turn archinstall into a universal installer backend, while archiso becomes a distribution definition layer.

👉 Together, they could replace the need for tools like Calamares in many Arch-based systems—while staying fully native and scriptable.

[guidryheal-create]

#4430 could help getting clues about how to reach an auto detect state profile, app state

[guidryheal-create]

With version

You may want to get the list of installed packages with their version, which is useful when reporting bugs or discussing installed packages.

List all explicitly installed packages: pacman -Qe
List all packages in the [package group](https://wiki.archlinux.org/title/Package_group) named group: pacman -Sg group
List all foreign packages (typically manually downloaded and installed or packages removed from the repositories): pacman -Qm
List all native packages (installed from the sync database): pacman -Qn
List all explicitly installed native packages (i.e. present in the sync database) that are not direct or optional dependencies: pacman -Qent
List packages by regex: pacman -Qs regex
List packages by regex with custom output format (needs [expac](https://archlinux.org/packages/?name=expac)): expac -s "%-30n %v" regex -- i imagine something like that but smarter ofc. issue is everything done without the use of standard archinstall installer. ( flatpak, install script, themes, etc )

[Torxed]

This feels like an Ai generated ticket, so I'll go ahead and close it as it doesn't make much sense in the current state it's written in.

There's not really anything called "ISO metadata", and archinstall is declarative..

[guidryheal-create]

interisting. so because i structure my request using AI it become bad ?

[guidryheal-create]

well then let s tell it otherwise. your code is poorly generalised. i need to rewrite more than one code file to supress and customize the app bunble and application and all that to make my archiso persist in a disk with a nice UI to customize it. calamares is not supported and well i just wana customize my theme to get fun with meme on a new VM with at least the right GPU drivers. I m lazy i don t wana rewrite the whole linux. and when i code everyone tell me Mhmm to good GPT did it. can you help me now ?