feat: interactive pkg-builder.toml creation and update wizard

[eniko1556]

Summary

Add an interactive pkg-builder init / pkg-builder update command that walks the user through creating or updating a pkg-builder.toml file step by step, with sensible defaults, auto-fetching of required metadata, and validation.

Motivation

Creating a pkg-builder.toml from scratch is tedious and error-prone. Users need to know the exact structure, manually look up GPG keys, find correct dotnet package URLs/hashes, determine runtime binary URLs and checksums, and remember which tool versions to pin. Updating an existing toml when bumping versions is equally painful — the user has to manually re-fetch hashes, update dotnet package lists, re-pin submodules, etc.

An interactive wizard that works for both new and existing tomls would drastically lower the barrier to entry and reduce human error during updates.

Core Modes

1. pkg-builder init — Create a new toml

Interactive walkthrough to generate a pkg-builder.toml from scratch.

2. pkg-builder update — Update an existing toml

Read the current pkg-builder.toml, detect what changed (e.g., version bump), and re-fetch/recompute affected fields:

• New version → re-fetch source tarball hash, update binary URLs/checksums
• Dotnet version bump → re-fetch entire dotnet package set with new hashes
• Git tag change → re-pin all submodule commits
• Distribution change → update workdir and tool versions
• Clear stale verify hashes so they get recomputed on next build

3. Snapshot mode — Auto-discover from existing state

Allow the wizard to figure things out from what already exists:

• Detect source type from an existing tarball or git repo in the working directory
• Inspect an existing Makefile or debian/ directory to infer recipe, dependencies, and build configuration
• Read an existing pkg-builder.toml and fill in missing or empty fields (e.g., compute hashes for entries that have hash = "")
• Auto-detect the distribution from the build environment or chroot
• Discover installed tool versions from the system

Proposed Walkthrough Flow (init mode)

1. [package] section

• Prompt for: package name, version, revision, homepage
• Auto-generate the spec filename from the package name
• Default revision to "1"

2. [source] section

• Ask source type: tarball or git
• If tarball: prompt for URL, auto-download and compute the hash (b2sum/sha256)
• If git: prompt for repo URL and tag
  • Offer to auto-discover and pin git submodules (fetch submodule list at that tag, resolve commit SHAs)

3. [build] section

• Prompt for target distribution (bookworm, trixie, noble, etc.) with autocomplete/list
• Prompt for architecture, default to amd64
• Auto-set workdir based on distribution (~/.pkg-builder/packages/{distribution})

4. [runtime] section

• Prompt for recipe/language: go, rust, nim, dotnet, dotnet-backup, java, java-gradle, javascript, typescript, c, virtual
• Per-recipe auto-fetching:
  • Go: Fetch latest stable Go binary URL and checksum from go.dev/dl/
  • Rust: Detect/suggest appropriate Rust toolchain
  • Nim: Fetch Nim binary URL and checksum, prompt for nim_version
  • Dotnet / dotnet-backup: Auto-fetch the full set of required dotnet packages (runtime, SDK, targeting packs, apphost, aspnetcore, etc.) with correct URLs and hashes for the selected dotnet version
  • Java / Java-Gradle: Prompt for JDK version, fetch appropriate URLs
  • C / Virtual: Minimal or no runtime config needed

5. [testing] section

• Offer toggles for lintian, piuparts, autopkgtest — default all to true

6. [tools] section

• Auto-populate with current/latest known tool versions (pkg_builder, debcrafter, sbuild, lintian, piuparts, autopkgtest)
• Allow override per tool

7. [verify] section

• Auto-generate empty package_hash entries based on package name/version/revision (.dsc and _amd64.deb)

8. GPG key handling

• If the source is fetched from an upstream that signs releases, offer to fetch and verify the GPG key
• Store/reference the key appropriately for the build

Additional Features

• --non-interactive mode: Accept all defaults or read from CLI flags for CI/scripting use
• Template support: Allow starting from a built-in template per language (e.g., pkg-builder init --template go)
• Validation: Validate URLs are reachable, hashes match, and the generated toml is well-formed before writing
• Version-aware defaults: When the user specifies a dotnet or Go version, fetch the matching set of packages/binaries automatically

Acceptance Criteria

• pkg-builder init produces a valid pkg-builder.toml for all supported recipes
• pkg-builder update detects version/config changes and re-fetches affected fields
• Snapshot mode can infer configuration from existing project state and fill in missing fields
• Dotnet package list is auto-fetched with correct hashes for a given version
• Git source type auto-discovers and pins submodules
• Tarball source type auto-computes hash
• GPG key fetching works for common upstreams
• Generated/updated toml passes pkg-builder build without manual edits (for supported recipes)