_____ _                         _                 _         _
  / ____| |                       | |               | |       | |
 | |    | |__  _ __ _   _ ___  ___| | __ _ _ __ ___ | |__   __| | __ _
 | |    |  _ \|  __| | | / __|/ _ \ |/ _` |  _   _ \|  _ \ / _  |/ _` |
 | |____| | | | |  | |_| \__ \ (_) | | (_| | | | | || |_) | (_| | (_| |
  \_____|_| |_|_|   \__, |___/\___/|_|\__,_|_| |_| |_|___/ \__,_|\__,_|
                      __/ |
                     |___/       W R I T E U P S

<<< Back to Index

Feasibility Writeup: Converting “All AUR Packages” to Guix Packages

Executive summary

Short answer: not fully feasible in a strict, complete sense (at least not in any near-term window), but highly feasible for a very large and useful subset with a disciplined pipeline.

AUR and Guix have very different philosophies:

• AUR: rolling, user-maintained build recipes tied to Arch ecosystem assumptions.
• Guix: reproducible, declarative packaging with strong purity expectations and service/module integration.

So this is less a “conversion” problem and more a continuous translation + curation problem.

Why full 1:1 conversion is unrealistic

1. Scale + churn mismatch

• AUR package count and update velocity are high.
• Many packages are abandoned, renamed, split, or transient.

2. Different build assumptions

• PKGBUILDs often assume Arch paths/tooling (pacman, FHS conventions, ad-hoc patching).
• Guix expects explicit dependencies, hermetic builds, and reproducibility constraints.

3. Licensing and source availability

• Some AUR packages wrap proprietary binaries or fetch from unstable/opaque sources.
• Guix packaging standards are stricter around source provenance and freedom.

4. Quality variance in AUR metadata

• Inconsistent checksums, non-canonical source URLs, optional dependency ambiguity.

5. Guix review/maintenance burden

• Even auto-generated package skeletons require human review for robustness and policy fit.

What *is* feasible

A staged program can likely convert a large high-value subset:

• popular dev tools
• CLI utilities
• language libraries with stable upstream release artifacts
• desktop apps with deterministic build systems

A practical target is not “all packages,” but:

1. Top N by usage/popularity

2. Packages meeting convertibility criteria

3. Ongoing sync for the convertible set

Convertibility tiers

Tier A (easy/automatable)

• Simple build systems: GNU make/CMake/Meson/Cargo/Go/Python standard flows
• Clear source tarballs/tags
• FOSS licensing
• Minimal Arch-specific patch logic

Tier B (semi-automatable)

• Complex dependency graphs
• Mixed build systems
• Needs patch adaptation and test adjustments

Tier C (hard/manual)

• Proprietary binaries / repackaged AppImages / unstable upstream artifacts
• Strong FHS assumptions
• Runtime network fetches or non-reproducible build steps

Tier D (out-of-scope / policy conflict)

• Unredistributable artifacts
• EULA constraints incompatible with normal Guix channels

Proposed action plan

Phase 0 — Define scope and success criteria

• Decide if goal is:
• community Guix upstream inclusion,
• private Guix channel,
• or hybrid model.
• Define KPIs:
• conversion success rate,
• build success across architectures,
• reproducibility score,
• maintenance latency.

Deliverables:

• CONVERSION_SCOPE.md
• Policy matrix (license/provenance/reproducibility)

Phase 1 — Build inventory + prioritization pipeline

• Mirror AUR metadata snapshot (names, votes, maintainers, source URLs, licenses).
• Score packages by:
• popularity
• dependency centrality
• source clarity
• build-system detectability
• policy risk

Deliverables:

• aur-inventory.json
• Prioritized queue (tier-a.csv, tier-b.csv, ...)

Phase 2 — PKGBUILD parser and translator

Build a translator that maps PKGBUILD concepts to Guix package skeletons:

• pkgname, pkgver, source, sha256sums, depends, makedepends, checkdepends
• map build phases to Guix arguments and build-system selection
• infer candidate Guix package names and modules

Deliverables:

• pkgbuild->guix converter CLI
• Generated .scm drafts with confidence scores

Phase 3 — Dependency mapping engine

• Resolve Arch/AUR dependency names to Guix package names.
• Maintain mapping DB with confidence levels and manual overrides.
• Auto-open “missing dependency” tickets for non-mapped deps.

Deliverables:

• dep-map.sqlite or dep-map.json
• reports for unresolved deps

Phase 4 — Reproducibility hardening

For each converted package:

• eliminate network access during build
• pin source commits/tarballs
• patch FHS assumptions
• run tests where feasible
• generate provenance and reproducibility metadata

Deliverables:

• reproducibility checklist
• patch set repository

Phase 5 — CI and build farm integration

• Build on CI with isolated containers/VMs.
• Validate install/runtime smoke tests.
• Capture logs/artifacts for triage.
• Optional: route successful outputs to a Guix channel branch.

Deliverables:

• CI pipelines
• dashboard (success/fail by tier)

Phase 6 — Human review + channel publishing

• Human reviewers approve generated package definitions.
• Publish approved packages to:
• private channel first,
• then upstream candidates where appropriate.

Deliverables:

• review workflow docs
• signed channel releases

Phase 7 — Continuous sync operations

• Daily/weekly AUR change ingestion.
• Diff-driven regeneration for changed PKGBUILDs.
• Regression detection on updates.

Deliverables:

• scheduled sync jobs
• maintainer alerting policy

What would be needed

People

• 1–2 Guix packaging experts
• 1 tooling engineer (parser/translator/CI)
• 1 infra engineer (build farm/cache)
• optional rotating reviewers/community maintainers

Infrastructure

• metadata mirror storage
• CI runners with enough CPU/RAM/disk
• binary cache (optional but recommended)
• issue tracker + package triage board

Software/tooling

• robust PKGBUILD parser (AST-level, not regex hacks)
• dependency mapping DB + override rules
• reproducibility/lint tooling for Guix package definitions
• dashboards for conversion status and failures

Governance

• clear policy for nonfree/proprietary packages
• acceptance criteria for channel inclusion
• maintenance SLA expectations by tier

Risks and mitigations

1. Translator brittleness

• Mitigation: confidence scoring + mandatory review for low-confidence outputs.

2. Dependency explosion

• Mitigation: prioritize strongly-connected/popular packages first; defer long tail.

3. Maintenance debt

• Mitigation: strict sunset policy for unmaintained conversions.

4. Policy drift (freedom/reproducibility)

• Mitigation: automated policy checks in CI gate.

Recommended strategy

If this were my project, I’d do:

1. Top-500 AUR packages pilot by weighted popularity and convertibility score.

2. Ship into a private Guix channel first.

3. Measure success metrics for 6–8 weeks.

4. Expand to top-2k only if:

• automated conversion precision is high,
• maintenance burden stays bounded.

That gives real utility fast without pretending “all AUR packages” is immediately tractable.

Bottom line

• Universal conversion: not realistically achievable as a one-time project.
• High-impact large subset: very achievable with disciplined automation + review.
• Success depends more on maintenance model than initial conversion speed.

<<< Back to Index