# apk Advanced: Version-Pinning und Custom Packages

TL;DR / Management Summary In der Welt von Alpine Linux ist Vorhersehbarkeit alles. Während ein einfaches apk add meist reicht, müssen wir in der Produktion sicherstellen, dass Versionen nicht unerwartet springen (Pinning). Zudem müssen wir wissen, wie wir Pakete aus dem edge Zweig sicher in ein stabiles System integrieren (Tagging) und wie wir mit abuild eigene APK-Pakete für interne Applikationen bauen. Dieses Modul macht Sie zum Alpine-Paket-Profi.

# 1. Einführung & Architektur

Die Welt der Tags.

Standardmäßig nutzt apk alle Repositories in der /etc/apk/repositories gleichwertig. Mit Tags können wir Repositories einen Namen geben und Pakete gezielt von dort anfordern.

# Die Repo-Logik (Mermaid)

graph LR
    A[SLES Host] --> B[/etc/apk/repositories]
    B --> C[main: v3.18]
    B --> D[community: v3.18]
    B --> E[@edge: http://.../edge/main]
    F[Admin: apk add pkg@edge] --> E
    G[Admin: apk add pkg] --> C

# 2. Version Pinning und Tags

Kontrolle über das Update.

# Pakete auf eine Version pinnen

Verhindern Sie, dass ein Paket bei apk upgrade aktualisiert wird.

# Fixiert auf exakte Version
apk add nginx=1.24.0-r1

# Fixiert auf Major/Minor Range (Asterisk)
apk add 'nginx<1.25'

# Repository Tags nutzen

Fügen Sie ein Repo mit einem Präfix hinzu:

# In /etc/apk/repositories
@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing

# Installation NUR aus diesem Repo
apk add my-beta-tool@testing

# 3. Eigene Pakete bauen mit abuild

Der Alpine-Bauhof.

Alpine nutzt das Tool abuild und ein APKBUILD File (ähnlich wie Archs PKGBUILD).

# Schritt 1: Build-Umgebung

sudo apk add alpine-sdk
sudo addgroup <user> abuild
# Keys generieren zum Signieren
abuild-keygen -a -i

# Schritt 2: Paket bauen

Erstellen Sie ein Verzeichnis mit einem APKBUILD.

abuild -r

Das fertige Paket landet unter ~/packages/.

# 4. Day-2 Operations: Local Repositories

Eigene Pakete sicher verteilen.

Um Ihre via abuild erstellten Pakete auf anderen Servern zu nutzen:

1. Kopieren Sie das .apk File auf einen Webserver.
2. Kopieren Sie den öffentlichen Schlüssel (.rsa.pub) nach /etc/apk/keys/ auf den Zielservern.
3. Fügen Sie die URL zur /etc/apk/repositories hinzu.

# 5. Troubleshooting & “War Stories”

Wenn die Versionen beißen.

# Story 1: “Der Key-Mismatch”

Symptom: apk add meldet “UNTRUSTED signature”, obwohl das Repo korrekt ist. Ursache: Der öffentliche Schlüssel für das Repository (vielleicht von einem Drittanbieter) fehlt im Ordner /etc/apk/keys/. Lösung: Laden Sie den .pub Key herunter und legen Sie ihn manuell ab. apk prüft nicht wie APT via GPG-Befehl, sondern schaut einfach in diesen Ordner.

# Story 2: “Dependency Hell in Edge”

Symptom: Nach der Installation eines Pakets aus @edge will das System das gesamte OS auf Edge-Libraries upgraden. Ursache: Das Edge-Paket benötigt eine neuere libc oder openssl als in Ihrem Stable-Release vorhanden ist. Lösung: Vermeiden Sie Mix-Ups von Core-Libraries! Wenn ein Paket zu viele neue Abhängigkeiten aus Edge zieht, bauen Sie es lieber selbst gegen Ihre Stable-Version (via abuild) oder nutzen Sie einen Container.

# 6. Fazit & Empfehlung

• Pinning: Nutzen Sie explizite Versionen in Dockerfiles, um “Broken Builds” zu vermeiden.
• Tags: Kennzeichnen Sie externe Repositories immer mit einem @tag, um unabsichtliche Upgrades zu verhindern.
• Signierung: Signieren Sie Ihre eigenen Pakete immer. Ein unsigniertes Repo ist ein massives Sicherheitsrisiko.

# Anhang: Cheatsheet