slackpkg+: Repositories und Paketverwaltung in Slackware erweitern

28.09.2026 · Zuletzt aktualisiert: 07.09.2026 · 9 Min. Lesezeit

Slackware verfolgt bei der Paketverwaltung einen bewusst konservativen Ansatz. Das Basissystem besteht aus sorgfältig zusammengestellten offiziellen Paketen, während zusätzliche Software häufig über separate Quellen oder durch eigene Builds bereitgestellt wird.

Wer Slackware64 15.0 intensiver nutzt, stößt deshalb schnell auf slackpkg+.

slackpkg+ erweitert den klassischen Paketmanager slackpkg um die Fähigkeit, zusätzliche Paket-Repositories einzubinden und gemeinsam mit dem offiziellen Slackware-Repository zu verwalten. Besonders interessant ist das für Multilib, AlienBOBs Pakete, zusätzliche Desktop-Komponenten und eigene Paketquellen.

Was ist slackpkg+?

slackpkg+ ist kein vollständig eigenständiger Paketmanager. Es handelt sich um eine Erweiterung für Slackwares slackpkg.

Die gewohnten Befehle bleiben erhalten:

slackpkg update
slackpkg install paket
slackpkg upgrade-all
slackpkg remove paket

slackpkg+ erweitert dabei insbesondere die Paketquellen, aus denen slackpkg seine Informationen bezieht.

Ohne Erweiterung arbeitet slackpkg hauptsächlich mit den offiziellen Slackware-Repositories.

Mit slackpkg+ kann beispielsweise folgende Struktur entstehen:

flowchart TD
    A[slackpkg] --> B[slackpkg+]
    B --> C[Slackware]
    B --> D[Multilib]
    B --> E[AlienBOB]
    C --> F[offiziell]
    D --> G["32 Bit"]
    E --> H[Zusatzpakete]

Dadurch erhält man eine einheitliche Oberfläche für Pakete aus unterschiedlichen Quellen.

Warum ist das für Slackware interessant?

Slackware hat kein zentrales Repository-Modell wie Debian oder Fedora.

Das ist Absicht.

Das offizielle Slackware-System soll überschaubar, stabil und vorhersehbar bleiben. Viele zusätzliche Programme werden deshalb außerhalb des eigentlichen Slackware-Baums angeboten.

Ein typisches System könnte beispielsweise folgende Quellen benötigen:

Slackware64 15.0
Slackware64 15.0 patches
Multilib
AlienBOB
eigenes Repository

Ohne slackpkg+ müsste man diese Quellen separat verwalten.

Mit slackpkg+ können sie in die Paketverwaltung integriert werden.

Die zentrale Konfigurationsdatei

Die wichtigste Datei ist:

/etc/slackpkg/slackpkgplus.conf

Dort werden unter anderem zusätzliche Repositorys definiert.

Das grundlegende Schema sieht beispielsweise so aus:

SLACKPKGPLUS=on

MIRRORPLUS['repository']=https://example.org/path/

Der Name repository ist dabei frei wählbar.

Beispielsweise:

MIRRORPLUS['multilib']=https://...

Anschließend kennt slackpkg+ dieses Repository unter dem Namen multilib.

Die eigentliche URL sollte immer aus der Dokumentation beziehungsweise vom Betreiber des jeweiligen Repositorys übernommen werden. Gerade bei Multilib ist es sinnvoll, die für die verwendete Slackware-Version passende Quelle zu verwenden.

Repositorys sind nicht alle gleich

Ein wichtiger Punkt beim Einsatz von slackpkg+ ist, dass zusätzliche Repositorys unterschiedliche Aufgaben haben können.

Man kann beispielsweise unterscheiden zwischen:

Offizielle Slackware-Pakete

Diese stammen direkt aus dem Slackware-Projekt:

slackware64-15.0/
patches/

Sie bilden die Grundlage des Systems.

Multilib

Multilib ergänzt Slackware64 um 32-Bit-Unterstützung.

Dort findet man unter anderem:

gcc-*multilib*
glibc-*multilib*

sowie kompatible 32-Bit-Pakete.

AlienBOB

AlienBOB stellt zahlreiche zusätzliche Slackware-Pakete bereit, die nicht Bestandteil der offiziellen Distribution sind.

Dazu gehören unter anderem größere Anwendungen und Paketsammlungen für bestimmte Anwendungsfälle.

Eigene Repositorys

Administratoren können auch eigene Paketquellen betreiben.

Das ist beispielsweise interessant für:

• selbst gebaute Pakete
• interne Software
• angepasste SlackBuilds
• Pakete für mehrere eigene Rechner

Repository-Prioritäten

Eines der wichtigsten Features von slackpkg+ ist:

PKGS_PRIORITY

Warum braucht man das?

Angenommen, im offiziellen Slackware-Repository befindet sich:

foo-1.0-x86_64-1

und ein zusätzliches Repository enthält:

foo-1.1-x86_64-1

Welches Paket soll slackpkg verwenden?

Genau dafür gibt es Prioritäten.

Eine beispielhafte Konfiguration:

PKGS_PRIORITY=( myrepo multilib )

bedeutet sinngemäß:

flowchart TD
    A[myrepo] --> B[multilib]
    B --> C[Slackware]

Ein Paket aus myrepo hat also Vorrang vor einem gleichnamigen Paket aus den nachfolgenden Quellen.

Warum Multilib ein gutes Beispiel ist

Multilib demonstriert sehr gut, warum Prioritäten notwendig sind.

Bei Slackware64 15.0 existieren offizielle Pakete für beispielsweise:

gcc
glibc

Multilib stellt für bestimmte Komponenten eigene Varianten bereit.

Diese müssen gegenüber den normalen Slackware-Paketen korrekt behandelt werden.

Ohne eine entsprechende Priorisierung besteht die Gefahr, dass ein späteres Update wieder die offizielle Slackware-Variante installiert.

Das wäre insbesondere bei zentralen Komponenten wie glibc und GCC problematisch.

Mit slackpkg+ lässt sich die gewünschte Paketquelle priorisieren.

Paketquellen gezielt aktivieren

Es ist nicht zwingend sinnvoll, jedes konfigurierte Repository permanent für jede Operation zu verwenden.

slackpkg+ bietet deshalb Mechanismen, um Repositorys gezielt einzubeziehen.

Das ist bei einer größeren Konfiguration sinnvoll:

flowchart TD
    A[Slackware] --> B[Multilib]
    A --> C[AlienBOB]
    A --> D["eigenes Repo"]
    A --> E["experimentelles Repo"]

Je mehr Quellen gleichzeitig aktiv sind, desto wichtiger wird es, genau zu wissen, welches Repository welche Pakete bereitstellt.

Das Grundprinzip sollte daher lauten:

So viele Quellen wie nötig, aber so wenige wie möglich.

Paketlisten aktualisieren

Nach Änderungen an den Repositorys müssen die Paketinformationen aktualisiert werden.

Typischerweise beginnt man mit:

slackpkg update

Bei Quellen, die eine eigene GPG-Signatur-Infrastruktur verwenden, kann zusätzlich ein GPG-Schritt erforderlich sein, beispielsweise:

slackpkg update gpg

Anschließend:

slackpkg update

Danach kennt slackpkg+ die Pakete aus den aktivierten Quellen.

Pakete suchen

Ein großer Vorteil ist die einheitliche Suche.

Zum Beispiel:

slackpkg search vlc

oder:

slackpkg search wine

Die Ergebnisse können dabei Pakete aus mehreren Quellen enthalten.

Das ist deutlich komfortabler als mehrere Websites oder Verzeichnisse manuell durchsuchen zu müssen.

Pakete installieren

Ist ein Paket verfügbar, kann es wie gewohnt installiert werden:

slackpkg install paketname

Beispielsweise:

slackpkg install foo

slackpkg+ übernimmt dabei die Auswahl aus den konfigurierten Paketquellen entsprechend den definierten Regeln.

Wichtig ist allerdings:

slackpkg+ ist kein klassischer Dependency Solver.

Das ist einer der größten Unterschiede zu Paketmanagern wie apt oder dnf.

Keine automatische Abhängigkeitsauflösung

Slackware-Pakete enthalten Informationen über ihren Inhalt, aber Slackware verfolgt traditionell nicht das gleiche automatische Abhängigkeitsmodell wie Debian oder Fedora.

Das bedeutet:

slackpkg install foo

bedeutet nicht automatisch:

flowchart TD
    A[foo] --> B["dependency A → installieren"]
    A --> C["dependency B → installieren"]
    A --> D["dependency C → installieren"]

Der Administrator bleibt für die Konsistenz seines Systems verantwortlich.

Das ist keine Schwäche, die slackpkg+ beheben soll.

Es ist vielmehr Teil der Slackware-Philosophie.

upgrade-all

Der wohl wichtigste Befehl im täglichen Betrieb ist:

slackpkg upgrade-all

Damit kann das System nach verfügbaren Aktualisierungen durchsucht werden.

In einer Konfiguration mit mehreren Repositories kann das beispielsweise bedeuten:

Slackware patches
       +
Multilib updates
       +
zusätzliche Repositorys

werden gemeinsam berücksichtigt.

Gerade für Multilib ist das sehr praktisch, weil man dadurch die zusätzlichen Pakete nicht ständig manuell überprüfen muss.

Vorsicht bei mehreren Repositories

Mehr Repositorys bedeuten nicht automatisch ein besseres System.

Nehmen wir an, drei Quellen enthalten jeweils ein Paket:

Slackware       foo-1.0
Repository A    foo-1.1
Repository B    foo-2.0

Ohne klare Prioritäten ist möglicherweise nicht sofort ersichtlich, welche Version letztendlich verwendet werden soll.

Noch problematischer wird es, wenn Repository B eine eigene Variante von Bibliotheken bereitstellt, die von anderen Paketen erwartet wird.

Deshalb sollte man bei slackpkg+ immer die Frage stellen:

Welche Quelle ist für dieses Paket die Autorität?

PKGS_PRIORITY

Eine häufige Fehlkonfiguration besteht darin, pauschal ein großes Repository an die erste Stelle zu setzen.

Beispielsweise:

PKGS_PRIORITY=( huge-third-party-repo )

Das kann dazu führen, dass dieses Repository nicht nur die gewünschten Zusatzprogramme liefert, sondern auch Pakete ersetzt, die eigentlich aus Slackware stammen sollten.

Besser ist eine bewusst geplante Struktur.

Zum Beispiel:

PKGS_PRIORITY=(
    multilib
    myrepo
)

wenn genau diese beiden Quellen Vorrang benötigen.

Dabei sollte man die Dokumentation des jeweiligen Repository-Betreibers beachten. Manche Repositorys empfehlen bestimmte Prioritäten oder spezielle Konfigurationsoptionen.

Das Zusammenspiel mit Slackware64 15.0

Eine sinnvolle Konfiguration für einen Slackware64-15.0-Desktop könnte konzeptionell so aussehen:

flowchart TD
    A["Slackware64 15.0"] --> B[slackpkg]
    A --> C[slackpkg+]
    C --> D["Slackware patches"]
    C --> E[Multilib]
    C --> F[AlienBOB]
    D --> G[Paketverwaltung]
    E --> G
    F --> G

Das Basissystem bleibt Slackware.

slackpkg+ sitzt darüber und vermittelt zwischen slackpkg und den zusätzlichen Quellen.

Multilib und slackpkg+ gemeinsam

Diese Kombination ist wahrscheinlich einer der bekanntesten Anwendungsfälle.

Ein Slackware64-15.0-System kann beispielsweise enthalten:

64-Bit Slackware
        +
Multilib GCC/glibc
        +
compat32 libraries

slackpkg+ kann dabei helfen, die Multilib-Pakete als zusätzliche Quelle zu verwalten.

Das reduziert insbesondere den manuellen Aufwand bei Updates.

Allerdings sollte man bei Multilib besonders sorgfältig arbeiten, weil glibc und GCC zentrale Komponenten des Systems sind.

Ein blindes:

slackpkg upgrade-all

ist daher kein Ersatz dafür, zu verstehen, welche Repositorys konfiguriert sind und welche Pakete sie bereitstellen.

Eigene Paketquellen

Eine der interessantesten Möglichkeiten von slackpkg+ ist die Verwendung eigener Repositorys.

Ein Administrator könnte beispielsweise einen internen Paketbestand aufbauen:

/srv/slackware/packages/

Darin könnten sich befinden:

company-tools
monitoring-agent
custom-kernel
internal-libraries

Mehrere Slackware-Rechner könnten anschließend auf dasselbe Repository zugreifen.

Damit wird aus slackpkg+ nicht nur ein Werkzeug für Desktop-Anwender, sondern auch ein interessantes Werkzeug für die Administration mehrerer Slackware-Systeme.

slackpkg+ und SlackBuilds.org sind unterschiedliche Dinge

Hier kommt es häufig zu Missverständnissen.

SlackBuilds.org stellt hauptsächlich Build-Skripte bereit.

Das Konzept lautet:

flowchart TD
    A[SlackBuild] --> B[Quellcode]
    B --> C["lokales Bauen"]
    C --> D["Slackware-Paket"]

slackpkg+ arbeitet dagegen primär mit bereits vorhandenen Paket-Repositories.

Das Konzept lautet:

flowchart TD
    A[Repository] --> B["fertiges Paket"]
    B --> C[slackpkg+]
    C --> D[Installation]

Die beiden Systeme können sich ergänzen.

Ein Administrator kann beispielsweise ein Paket mit einem SlackBuild bauen und anschließend das erzeugte Paket in ein eigenes Repository aufnehmen.

Was slackpkg+ nicht ersetzen soll

slackpkg+ ist kein universeller Ersatz für alle Slackware-Werkzeuge.

Ein typischer Werkzeugkasten kann weiterhin aus mehreren Komponenten bestehen:

flowchart LR
    A[slackpkg] --> A1["offizielles Slackware-System"]
    B[slackpkg+] --> B1["zusätzliche Binär-Repositories"]
    C[installpkg] --> C1["einzelnes lokales Paket installieren"]
    D[upgradepkg] --> D1["lokales Paket aktualisieren"]
    E[removepkg] --> E1["Paket entfernen"]
    F["sbopkg / SlackBuilds.org"] --> F1["Software aus Quellen bauen"]
    G[pkgtools] --> G1["grundlegende Paketverwaltung"]

Jedes Werkzeug erfüllt einen anderen Zweck.

Warum slackpkg+ gut zur Slackware-Philosophie passt

Auf den ersten Blick könnte slackpkg+ wie ein Schritt weg von Slackwares Philosophie wirken.

Tatsächlich ist eher das Gegenteil der Fall.

Slackware sagt nicht:

Es darf nur Software aus dem offiziellen Repository installiert werden.

Die Philosophie ist vielmehr:

Der Administrator entscheidet, welche Software auf seinem System landet.

slackpkg+ macht diese Entscheidung lediglich komfortabler.

Der Administrator entscheidet weiterhin:

• Welche Repositorys werden verwendet?
• Welche Quelle bekommt Priorität?
• Welche Pakete werden installiert?
• Welche Pakete werden aktualisiert?
• Welche zusätzlichen Softwarequellen sind vertrauenswürdig?

Das Repository-Modell bleibt damit transparent.

Sicherheitsaspekt: Repositorys sind Vertrauensbeziehungen

Ein zusätzlicher Paketbestand ist nicht nur eine technische Quelle.

Er ist auch eine Vertrauensbeziehung.

Wenn ein Repository aktiviert wird, erlaubt man seinem Betreiber faktisch, Software auf dem eigenen System bereitzustellen.

Deshalb sollte man Repositorys nicht wahllos hinzufügen.

Besonders wichtig sind:

• vertrauenswürdiger Betreiber
• passende Slackware-Version
• Paket-Signaturen
• nachvollziehbare Herkunft
• klare Dokumentation
• regelmäßige Pflege

Gerade bei Systempaketen sollte man nicht einfach mehrere Repositorys kombinieren, ohne ihre gegenseitige Kompatibilität zu prüfen.

Eine gute Grundstrategie

Für Slackware64 15.0 ist eine konservative Strategie sinnvoll:

flowchart TD
    A["1. Slackware offiziell"] --> B["2. Slackware patches"]
    B --> C["3. Multilib, falls benötigt"]
    C --> D["4. wenige ausgewählte Zusatz-Repositories"]
    D --> E["5. eigene Pakete"]

Nicht jedes interessante Repository muss dauerhaft aktiviert werden.

Je kleiner und übersichtlicher die Paketlandschaft bleibt, desto einfacher ist es, ein Slackware-System langfristig zu warten.

Fazit

slackpkg+ erweitert Slackwares klassische Paketverwaltung um ein Repository-Modell, ohne die grundlegende Slackware-Philosophie aufzugeben.

Die wichtigsten Konzepte sind:

flowchart TD
    A[slackpkg] --> B[slackpkg+]
    B --> C["offizielle Slackware-Pakete"]
    B --> D[Multilib]
    B --> E["zusätzliche Binär-Repositories"]
    B --> F["eigene Paketquellen"]

Besonders mächtig sind dabei:

• MIRRORPLUS
• PKGS_PRIORITY
• Repository-Signaturen
• die Integration mit slackpkg
• die gemeinsame Aktualisierung mehrerer Paketquellen

Für Slackware64 15.0 ist slackpkg+ besonders interessant, wenn ein System über das reine Slackware-Basissystem hinausgeht – etwa durch Multilib, AlienBOB-Pakete oder eigene Pakete.

Der wichtigste Grundsatz bleibt jedoch:

slackpkg+ macht mehrere Repositorys bequem verwaltbar – es macht sie nicht automatisch kompatibel.

Gerade deshalb sollte man bei Slackware nicht möglichst viele Paketquellen aktivieren, sondern eine kleine, bewusst ausgewählte und klar priorisierte Repository-Landschaft pflegen.