Slackware Extras
30.08.2026 17 Min. Lesezeit
Wer Slackware zum ersten Mal genauer betrachtet, stößt im offiziellen Repository neben dem eigentlichen Paketbaum auf Verzeichnisse wie patches/, testing/, pasture/ und extra/.
Gerade extra/ wirkt zunächst rätselhaft.
Wenn Slackware ein Paket bereits gebaut und offiziell bereitstellt - warum befindet es sich dann nicht einfach im normalen Paketbaum?
Und wenn es nicht zum Basissystem gehört: Ist es dann überhaupt “offiziell”?
Die Antwort führt direkt zum Kern der Slackware-Philosophie.
extra/ ist eine bewusst getrennte Sammlung zusätzlicher Software, die vom Slackware-Projekt bereitgestellt wird, aber nicht Bestandteil der normalen Slackware-Paketserien ist.
Diese Trennung ist keine zufällige Organisation des FTP-Verzeichnisses. Sie erfüllt eine konkrete Funktion: Slackware kann zusätzliche Software anbieten, ohne damit die Definition dessen zu verändern, was zum eigentlichen Betriebssystem gehört.
Der Ausgangspunkt: Slackware ist mehr als eine Paketliste
Um extra/ richtig zu verstehen, muss man zunächst die Struktur einer Slackware-Distribution betrachten.
Bei Slackware64 15.0 findet man auf dem offiziellen Repository unter anderem:
slackware64-15.0/
├── slackware64/
├── patches/
├── extra/
├── source/
├── testing/
├── pasture/
├── kernels/
└── ...
Diese Verzeichnisse sind nicht einfach verschiedene Paketquellen mit identischer Bedeutung.
Sie repräsentieren unterschiedliche Ebenen innerhalb des Slackware-Projekts.
Der wichtigste Bereich ist:
slackware64/
Hier befinden sich die offiziellen Paketserien, aus denen das eigentliche Slackware-System besteht.
Daneben existieren Bereiche für unterschiedliche Zwecke.
patches/ enthält Aktualisierungen für die veröffentlichte Distribution.
testing/ dient der Erprobung neuer oder veränderter Komponenten.
pasture/ enthält Software, die aus verschiedenen Gründen aus dem normalen Bestand entfernt wurde, aber weiterhin bereitgestellt werden kann.
Und dann gibt es:
extra/
Das Konzept von extra/ ist anders.
Es geht nicht primär um eine Entwicklungsstufe eines Pakets, sondern um zusätzliche Software außerhalb des definierten Basissystems. Die aktuelle offizielle Repository-Struktur für Slackware64 15.0 führt extra/ weiterhin als separaten Bereich; dort werden neben Paketlisten und Checksummen auch eigene Unterverzeichnisse für die jeweiligen Zusatzpakete geführt.
Die entscheidende Unterscheidung: “offiziell” ist nicht dasselbe wie “Bestandteil”
Das ist vermutlich der wichtigste Gedanke beim Verständnis von Slackware extra.
Man muss zwei Begriffe auseinanderhalten:
offiziell vom Slackware-Projekt bereitgestellt
und
Bestandteil des Slackware-Basissystems
Ein Paket kann das erste erfüllen, ohne das zweite zu erfüllen.
Genau das ist der Sinn von extra/.
Vereinfacht:
Slackware-Projekt
│
┌─────────────┴─────────────┐
│ │
Basissystem Extras
│ │
slackware64/ extra/
│ │
notwendige bzw. optionale
reguläre Pakete Zusatzsoftware
Das bedeutet:
Ein Paket in extra/ ist nicht automatisch ein „fremdes“ oder „inoffizielles“ Paket.
Es ist vielmehr ein offiziell bereitgestelltes optionales Paket.
Diese Unterscheidung ist für die gesamte Slackware-Architektur wichtig.
Warum gibt es überhaupt ein extra/?
Die naheliegende Frage lautet:
Warum nimmt man die Pakete nicht einfach in
slackware64/auf?
Die Antwort ergibt sich aus Slackwares Grundprinzipien.
Slackware versucht, ein System bereitzustellen, das:
- nachvollziehbar,
- stabil,
- relativ schlank,
- modular,
- administrativ transparent
ist.
Wenn jedes nützliche Programm automatisch Teil der Standarddistribution wäre, würde das Basissystem immer größer und seine Definition immer unschärfer.
Nehmen wir hypothetisch an, Slackware würde jede denkbare Software direkt in den normalen Paketbaum aufnehmen:
Browser
Mailserver
Datenbankserver
zusätzliche Shells
Entwicklungsumgebungen
Accessibility-Software
Multimedia-Werkzeuge
Spezialbibliotheken
alternative Server
...
Dann müsste die Distribution ständig entscheiden:
Was gehört eigentlich noch zum Betriebssystem?
Slackware löst dieses Problem nicht durch eine riesige Hierarchie von optionalen Installationsprofilen, sondern unter anderem durch räumliche und konzeptionelle Trennung.
Das Basissystem bleibt definiert.
Zusätzliche Software kann trotzdem angeboten werden.
Dafür gibt es extra/.
extra/ ist kein “Müllverzeichnis”
Ein verbreitetes Missverständnis besteht darin, extra/ als eine Art Ablage für Pakete zu betrachten, die es „nicht in Slackware geschafft haben“.
Das ist zu einfach.
Ein Paket kann in extra/ liegen, obwohl es technisch einwandfrei funktioniert und vom Slackware-Projekt bereitgestellt wird.
Der Grund für die Trennung kann vielmehr sein, dass es:
- nur für einen Teil der Anwender interessant ist,
- eine alternative Implementierung darstellt,
- spezielle zusätzliche Abhängigkeiten benötigt,
- eine bestimmte Zielgruppe bedient,
- eine historische oder besondere Funktion erfüllt,
- nicht in die Standardauswahl passt.
extra/ beantwortet daher nicht primär die Frage:
Ist diese Software gut genug?
Sondern eher:
Soll diese Software Bestandteil der Standardinstallation beziehungsweise des regulären Paketsets sein?
Das sind zwei völlig unterschiedliche Fragen.
Ein Blick auf die reale Struktur von Slackware 15.0
Die aktuelle Struktur von Slackware64 15.0 macht dieses Konzept sehr deutlich.
Das offizielle Repository enthält getrennte Bereiche für:
slackware64/
patches/
extra/
source/
testing/
pasture/
Dabei werden für extra/ eigene Metadaten geführt:
CHECKSUMS.md5
CHECKSUMS.md5.asc
FILE_LIST
MANIFEST.bz2
PACKAGES.TXT
README.TXT
Das ist ein wichtiges Detail.
extra/ ist nicht einfach ein zufällig abgelegtes Verzeichnis mit ein paar .txz-Dateien. Es besitzt eine strukturierte Paketlandschaft mit den für Slackware üblichen Repository-Metadaten.
Damit wird auch klar, warum die Bezeichnung „inoffizielle Software“ irreführend wäre.
Das README.TXT ist historisch interessant
Im extra/-Verzeichnis findet sich ein bemerkenswert kleines:
README.TXT
Die Datei stammt aus dem Jahr 2002.
Das ist typisch für Slackware.
Das Konzept von extra/ ist nicht erst mit Slackware 15.0 entstanden. Das Verzeichnis ist ein historisch gewachsener Bestandteil des Slackware-Repository-Modells.
Interessant ist dabei weniger der Umfang der Dokumentation als die Tatsache, dass die Struktur über viele Slackware-Generationen hinweg erhalten geblieben ist.
Das spricht dafür, dass extra/ nicht als kurzfristige Lösung für ein bestimmtes Release gedacht war.
Es ist ein Bestandteil der langfristigen Repository-Organisation.
Warum extra/ nicht wie slackware64/ behandelt wird
Jetzt kommt der nächste wichtige Punkt.
Wenn extra/ einfach ein zweiter offizieller Paketbaum wäre, könnte man ihn genauso in die normale Paketverwaltung integrieren.
Genau das ist aber nicht grundsätzlich der Fall.
Die Standardkonfiguration von slackpkg orientiert sich am eigentlichen Slackware-Paketbaum und dessen Patches.
extra/ wird nicht automatisch zum Bestandteil einer normalen slackpkg-Installation.
Das ist kein Versehen.
Es entspricht dem Konzept:
Standardinstallation
│
▼
slackware64/
patches/
│
▼
bewusst ausgewählte Extras
│
▼
extra/
Der Administrator entscheidet also explizit, ob er ein Extra verwenden möchte.
Das ist ein Ausdruck von Slackwares Modularität
Man kann das Konzept mit einem Baukastensystem vergleichen.
Das eigentliche Slackware-System bildet die Grundkonstruktion:
┌───────────────────────────┐
│ Slackware64 │
│ │
│ Kernel │
│ libc │
│ Shells │
│ Core utilities │
│ Libraries │
│ Networking │
│ Desktop │
│ ... │
└───────────────────────────┘
extra/ liefert zusätzliche Bausteine:
┌──────────────┐
│ Extra A │
└──────────────┘
┌──────────────┐
│ Extra B │
└──────────────┘
┌──────────────┐
│ Extra C │
└──────────────┘
Nicht jeder Benutzer braucht jeden Baustein.
Deshalb gehören sie nicht automatisch zum Fundament.
extra/ ist dabei nicht dasselbe wie testing/
Diese beiden Verzeichnisse werden gelegentlich verwechselt.
Der Unterschied ist konzeptionell fundamental.
testing/
Hier geht es um Entwicklung und Erprobung.
Ein Paket kann dort landen, weil eine neue Version oder ein neuer Ansatz getestet werden soll.
Das zentrale Kriterium ist:
Ist diese Software beziehungsweise diese Änderung bereits bereit für den normalen Einsatz?
extra/
Hier lautet die Frage eher:
Gehört diese Software überhaupt in den normalen Paketbestand?
Das bedeutet:
testing
│
└── Entwicklungs-/Stabilitätsstatus
extra
│
└── Bestandteil oder nicht Bestandteil
des Standardpaketsatzes
Ein Paket in extra/ ist daher nicht automatisch experimentell.
extra/ ist auch nicht dasselbe wie patches/
Auch patches/ hat eine völlig andere Aufgabe.
Ein Patch korrigiert oder aktualisiert ein bereits zum Release gehörendes Paket.
Beispielsweise konzeptionell:
Slackware 15.0
│
└── foo-1.0
│
▼
Sicherheitsproblem
│
▼
patches/foo-1.1
extra/ funktioniert anders:
Slackware 15.0
│
├── foo
│
└── optionales Zusatzprogramm
│
▼
extra/
patches/ hält das definierte System aktuell.
extra/ erweitert das definierte System.
Und was ist mit pasture/?
Auch pasture/ ist ein interessantes Gegenstück.
Dort kann Software liegen, die aus dem normalen Paketbestand entfernt wurde, aber aus Gründen der Kompatibilität oder für Nutzer älterer Systeme noch verfügbar gehalten wird.
Damit ergeben sich vier unterschiedliche Konzepte:
| Bereich | Grundidee |
|---|---|
slackware64/ | regulärer Bestandteil |
patches/ | Aktualisierung des regulären Bestands |
testing/ | Erprobung neuer/änderter Komponenten |
extra/ | optionale Ergänzungen |
pasture/ | aus dem regulären Bestand entfernte Software |
Diese Unterscheidung ist wesentlich besser als die vereinfachte Vorstellung:
Alles unterhalb des Slackware-Mirrors sind einfach Pakete.
Nein.
Die Verzeichnisstruktur enthält Informationen über die Rolle eines Pakets innerhalb des Projekts.
Was findet man tatsächlich in extra/?
Der Inhalt verändert sich über die Zeit.
Für Slackware64 15.0 existieren unter anderem Verzeichnisse wie:
aspell-word-lists/
bash-completion/
bittornado/
brltty/
...
Die vollständige aktuelle Liste sollte man direkt im offiziellen Repository beziehungsweise in PACKAGES.TXT betrachten, denn extra/ ist kein statischer Bestandteil, der seit dem Release unverändert geblieben ist. Das offizielle Slackware-Mirrorverzeichnis weist für Slackware64 15.0 auch 2026 noch aktuelle Metadaten und Änderungen im extra/-Bereich aus.
Das ist ein wichtiger Punkt:
Slackware 15.0 bleibt als Release 15.0 bestehen, während der zugehörige Repository-Bestand – insbesondere
patches/und Teile vonextra/– weiter gepflegt werden kann.
Man sollte deshalb nicht automatisch annehmen, dass extra/ exakt dem Inhalt der ursprünglichen 15.0-DVD entspricht.
Das führt zu einer wichtigen Unterscheidung: Release gegen Repository-Zustand
Slackware 15.0 wurde am 2. Februar 2022 veröffentlicht. Die offizielle Projektseite beschreibt 15.0 als stabile Veröffentlichung und verweist für zusätzliche Software unter anderem auf SlackBuilds.org.
Der heutige Mirror-Baum ist dagegen ein lebender Repository-Zustand.
Das bedeutet:
Slackware 15.0 Release
│
├── ursprünglicher Paketbestand
│
└── später gepflegter Repository-Bestand
│
├── patches
└── extra
Wer heute ein Paket aus extra/ installiert, sollte deshalb immer berücksichtigen:
„Slackware 15.0“ bezeichnet die Release-Basis, nicht zwingend den historischen Stand jedes einzelnen Repository-Eintrags.
extra/ und das Prinzip der bewussten Installation
Ein typisches Slackware-System entsteht daher schrittweise.
Zuerst:
Slackware64 15.0
Dann entscheidet der Administrator:
Brauche ich X?
Brauche ich Y?
Brauche ich Z?
Beispielsweise:
Basissystem
│
├── Extra A → ja
├── Extra B → nein
├── Extra C → ja
└── Extra D → nein
Das ist ein wichtiger Unterschied zu Distributionen, die ihre Paketauswahl stärker über Metapakete, Rollen oder automatische Abhängigkeiten organisieren.
Slackware lässt die Entscheidung stärker beim Administrator.
Das erklärt auch die Rolle von installpkg
Ein Paket aus extra/ ist technisch weiterhin ein Slackware-Paket.
Wenn man beispielsweise ein .txz-Paket heruntergeladen hat, kann man es mit den normalen Slackware-Paketwerkzeugen installieren:
installpkg paketname.txz
oder ein vorhandenes Paket aktualisieren:
upgradepkg paketname.txz
Das extra/-Verzeichnis definiert also keine neue Pakettechnik.
Es definiert eine Repository-Kategorie.
Das ist ein wichtiger Unterschied.
Man braucht keinen speziellen „Extra-Paketmanager“.
Warum das Konzept so elegant ist
Aus Sicht des Paketformats wäre es völlig unnötig, für Extras ein neues Format zu erfinden.
Ein Slackware-Paket bleibt ein Slackware-Paket:
foo-1.2.3-x86_64-1.txz
Der Unterschied ist seine Position im Repository:
slackware64/foo/...
gegenüber:
extra/foo/...
Die technische Paketmechanik bleibt gleich.
Die semantische Bedeutung ändert sich.
Das ist typisch für Unix-artige Systeme: Die Organisation der Dateien und Verzeichnisse transportiert einen Teil der Systemarchitektur.
Warum extra/ besonders gut zu Slackware passt
Man kann die Philosophie hinter extra/ auf einen einfachen Satz reduzieren:
Nicht alles, was nützlich ist, muss Bestandteil des Grundsystems sein.
Das klingt banal, hat aber weitreichende Folgen.
Ein Administrator kann ein System bauen, das beispielsweise nur aus dem offiziellen Bestand besteht:
Slackware64
+
Patches
Ein anderer kann daraus machen:
Slackware64
+
Patches
+
Extras
+
Multilib
+
AlienBOB
+
SlackBuilds
Beide Systeme sind legitim.
Slackware schreibt nicht vor, dass jede Installation dieselbe Softwareausstattung haben muss.
extra/ gegenüber SlackBuilds.org
Ein besonders wichtiger Vergleich ist Slackware extra/ mit SlackBuilds.org.
Die beiden verfolgen unterschiedliche Modelle.
Slackware extra/
Slackware-Projekt
│
▼
Build
│
▼
fertiges Paket
│
▼
extra/
SlackBuilds.org
Community
│
▼
SlackBuild + Quellenangaben
│
▼
lokaler Build
│
▼
eigenes Slackware-Paket
Die offizielle Slackware-Projektseite weist ausdrücklich darauf hin, dass SlackBuilds.org Build-Skripte für zusätzliche Software bereitstellt.
extra/ und SlackBuilds.org sind deshalb keine konkurrierenden Varianten desselben Systems.
Sie beantworten unterschiedliche Fragen:
extra/:
Welche zusätzliche Software stellt Slackware selbst als fertiges Paket bereit?
SlackBuilds.org:
Wie kann ich zusätzliche Software nach dem Slackware-Build-Prinzip selbst als Paket bauen?
Der nächste logische Schritt: eigene Pakete
Das extra-Konzept führt fast automatisch zu einem weiteren Slackware-Prinzip.
Wenn Slackware ein Paket nicht automatisch in das Basissystem aufnehmen muss, kann auch der Administrator eigene Pakete bauen.
Der typische Weg lautet:
Quellcode
│
▼
SlackBuild
│
▼
Slackware-Paket
│
▼
/var/log/packages/
Damit bleibt auch selbst gebaute Software in der Slackware-Paketverwaltung sichtbar.
Das ist ein wesentlich saubererer Ansatz als:
make install
und anschließend nicht mehr genau zu wissen, welche Dateien installiert wurden.
extra/ vermittelt daher indirekt eine wichtige Idee:
Zusätzliche Software soll nicht das Basissystem verändern, sondern als nachvollziehbares Paket ergänzt werden.
Warum extra/ kein normales „Third-Party Repository“ ist
Hier muss man nochmals genau unterscheiden.
Ein typisches externes Repository kann von einer Einzelperson oder Community betrieben werden.
extra/ liegt dagegen innerhalb der offiziellen Slackware-Distribution:
slackware64-15.0/
└── extra/
Es besitzt dieselben Repository-Metadatenmechanismen wie der übrige Slackware-Bestand.
Das macht extra/ zu einem Sonderfall:
offiziell
│
├── Bestandteil des Kernsystems
│
└── offiziell bereitgestellte Extras
Man sollte es deshalb nicht mit einem beliebigen Drittanbieter-Repository gleichsetzen.
Aber: “offiziell” bedeutet nicht “automatisch erforderlich”
Das ist der entscheidende zweite Teil.
Ein offizielles Extra ist nicht deshalb Bestandteil einer normalen Installation, weil Slackware es anbietet.
Genau umgekehrt:
Es ist optional, weil Slackware bewusst entschieden hat, dass es nicht Teil des normalen Paketsatzes sein muss.
Das ermöglicht eine sehr klare Trennung:
Was braucht Slackware?
│
▼
slackware64/
Was braucht dieses spezielle System zusätzlich?
│
▼
extra/
Damit wird die Distribution nicht durch die Bedürfnisse einer bestimmten Benutzergruppe definiert.
Ein Beispiel aus Sicht eines Administrators
Nehmen wir einen Administrator, der einen kleinen Slackware-Server betreibt.
Er benötigt:
SSH
Webserver
DNS
Logging
Firewall
Er muss nicht automatisch alle Desktop- und Zusatzkomponenten installieren.
Ein anderer Benutzer betreibt dagegen eine Workstation:
KDE
Audio
Grafik
Entwicklung
Wine
zusätzliche Tools
Die Basis kann identisch sein:
Slackware64 15.0
Die eigentliche Softwareausstattung unterscheidet sich.
extra/ ist ein Teil des Mechanismus, mit dem diese Unterschiede sauber organisiert werden können.
Warum Slackware nicht einfach „alles installiert“
Hier liegt ein fundamentaler Unterschied zu einer stärker automatisierten Distribution.
Ein automatisiertes System könnte sagen:
Du installierst Desktop X, deshalb installiere ich automatisch 500 weitere Pakete.
Slackware bevorzugt einen expliziteren Ansatz.
Natürlich existieren auch in Slackware Paketabhängigkeiten und Paketsammlungen. Aber die Distribution versucht nicht, aus jeder optionalen Software eine automatische Kette von Entscheidungen zu machen.
Das Ergebnis ist ein System, dessen tatsächlicher Aufbau für einen Administrator relativ gut nachvollziehbar bleibt.
extra/ unterstützt genau diese Transparenz.
Die Paketverwaltung bleibt bewusst einfach
Ein Paket aus extra/ wird nicht zu einer besonderen Paketklasse.
Die bekannten Werkzeuge bleiben:
installpkg
upgradepkg
removepkg
pkgtool
und für Repository-basierte Verwaltung:
slackpkg
Mit slackpkg+ kann man zusätzliche Repositorys integrieren. extra/ selbst ist allerdings bereits Bestandteil des offiziellen Slackware-Baums und sollte deshalb nicht gedanklich mit einem beliebigen externen Repository gleichgesetzt werden.
Das zeigt nochmals:
extra/
│
└── organisatorische Trennung
Slackware-Paketformat
│
└── unverändert
Ein Blick auf die Repository-Hierarchie
Die Slackware-Struktur lässt sich deshalb als eine Art Informationsarchitektur lesen:
Slackware64 15.0
│
├── slackware64/
│ └── Was gehört zum System?
│
├── patches/
│ └── Was muss am System korrigiert/aktualisiert werden?
│
├── testing/
│ └── Was wird erprobt?
│
├── pasture/
│ └── Was ist aus dem regulären Bestand herausgefallen?
│
└── extra/
└── Was ist zusätzlich nützlich, aber nicht Teil
des normalen Basispaketsatzes?
Damit ist extra/ kein isoliertes Feature.
Es ergibt erst zusammen mit den anderen Repository-Bereichen ein vollständiges Bild davon, wie Slackware Software organisiert.
Warum das für langfristige Wartung wichtig ist
Ein Slackware-System kann viele Jahre betrieben werden.
Je stärker man unterschiedliche Softwarequellen vermischt, desto schwieriger wird es irgendwann, die Herkunft einzelner Pakete zu verstehen.
Bei einer sauberen Installation kann man dagegen gedanklich unterscheiden:
offizielles Slackware
│
├── patches
│
└── extras
zusätzliche Quellen
│
├── Multilib
├── AlienBOB
└── eigene Pakete
Das ist bei Fehleranalyse und Upgrades sehr hilfreich.
Wenn beispielsweise eine Bibliothek Probleme verursacht, ist die erste Frage:
Aus welcher Paketquelle stammt sie?
Eine klare Repository-Struktur erleichtert die Antwort.
extra/ als Kompromiss zwischen Minimalismus und Vollständigkeit
Hier liegt wahrscheinlich die eleganteste Erklärung des gesamten Konzepts.
Eine Distribution hat zwei gegensätzliche Anforderungen:
Minimalismus
Das System soll nicht mit Software überladen werden, die niemand benötigt.
Vollständigkeit
Der Benutzer soll trotzdem nicht alles selbst suchen und bauen müssen.
extra/ bildet den Kompromiss:
Minimalistisches Basissystem
│
▼
Slackware64
│
+
│
offizielle optionale Pakete
│
▼
extra/
Slackware kann also schlank bleiben und trotzdem zusätzliche Software anbieten.
Der Name “extra” ist deshalb treffend
Der Begriff ist bewusst unspektakulär.
Nicht:
unsupported/
experimental/
random/
community/
sondern:
extra/
Das beschreibt die Rolle ziemlich genau:
Es ist Slackware – aber zusätzlich zum normalen Paketbestand.
Diese Einfachheit passt wiederum zur allgemeinen Slackware-Philosophie.
Wie man extra/ praktisch benutzt
Wer ein bestimmtes Extra benötigt, kann zunächst das offizielle Repository durchsuchen.
Für Slackware64 15.0 steht beispielsweise das offizielle Verzeichnis zur Verfügung.
Dort findet man Unterverzeichnisse für einzelne Softwarepakete sowie:
PACKAGES.TXT
FILE_LIST
CHECKSUMS.md5
CHECKSUMS.md5.asc
Ein lokales Paket kann anschließend beispielsweise mit:
installpkg /pfad/zum/paket.txz
installiert werden.
Für ein bereits installiertes Paket kommt:
upgradepkg /pfad/zum/neuen-paket.txz
zum Einsatz.
Wichtig ist dabei, dass man die passende Architektur verwendet:
slackware64-15.0
für ein 64-Bit-System und nicht versehentlich:
slackware-15.0
für die 32-Bit-Variante.
extra/ und slackpkg+
An dieser Stelle lässt sich auch die Verbindung zum vorherigen Artikel über slackpkg+ herstellen.
extra/ und slackpkg+ lösen unterschiedliche Probleme.
extra/ beantwortet:
Welche optionalen Pakete stellt Slackware offiziell bereit?
slackpkg+ beantwortet:
Wie kann ich zusätzliche Paketquellen in meine slackpkg-basierte Verwaltung integrieren?
Daraus ergibt sich:
Slackware
│
├── slackware64/
├── patches/
└── extra/
│
▼
offizieller Bestand
slackpkg+
│
├── Multilib
├── AlienBOB
└── weitere Repositories
│
▼
zusätzliche Quellen
Die beiden Konzepte ergänzen sich, sind aber nicht dasselbe.
Ein häufiger Denkfehler
Man sollte nicht denken:
Wenn ein Paket in
extra/liegt, ist es weniger vertrauenswürdig.
Ebenso falsch wäre:
Wenn es offiziell ist, muss ich es installieren.
Beides folgt nicht aus der Struktur.
Die korrekte Interpretation lautet:
Slackware stellt dieses Paket offiziell zur Verfügung, ordnet es aber bewusst außerhalb des regulären Basispaketsatzes ein.
Damit ist die Kategorie extra/ vor allem eine Aussage über Rolle und Umfang, nicht über die grundsätzliche Vertrauenswürdigkeit eines Pakets.
Die philosophische Ebene
Slackware ist in dieser Hinsicht bemerkenswert konsequent.
Die Distribution versucht nicht, dem Benutzer jede Entscheidung abzunehmen.
Stattdessen liefert sie:
Werkzeuge
+
Pakete
+
Quellen
+
Dokumentation
und überlässt einen Teil der Systemarchitektur dem Administrator.
extra/ ist eine direkte Folge dieser Philosophie.
Es sagt:
Hier ist zusätzliche Software, die wir für sinnvoll halten.
Aber nicht:
Diese Software muss auf jedem Slackware-System vorhanden sein.
Das ist ein kleiner Unterschied in der Formulierung, aber ein großer Unterschied im Design.
Ein Modell zum Verständnis
Man kann Slackwares Paketwelt deshalb als konzentrische Ebenen betrachten:
┌───────────────────────────────────────┐
│ Slackware-Welt │
│ │
│ ┌─────────────────────────────────┐ │
│ │ offizielles Release │ │
│ │ │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ slackware64/ │ │ │
│ │ │ Basissystem │ │ │
│ │ └─────────────────────────┘ │ │
│ │ │ │
│ │ patches/ │ │
│ │ │ │
│ │ extra/ │ │
│ │ │ │
│ └─────────────────────────────────┘ │
│ │
│ externe Quellen / eigene Pakete │
│ │
└───────────────────────────────────────┘
Dabei ist extra/ noch Teil der offiziellen Slackware-Welt.
Multilib, AlienBOB oder eigene Repositories liegen konzeptionell eine Stufe weiter außen.
Das ist natürlich kein formales Architekturdiagramm, aber als Denkmodell sehr nützlich.
Was extra/ ausdrücklich nicht bedeutet
Zum Abschluss lohnt sich eine Negativdefinition.
extra/ bedeutet nicht:
- dass die Software experimentell ist,
- dass die Software unfertig ist,
- dass die Software von der Community stammt,
- dass sie nicht gepflegt wird,
- dass sie nicht mit Slackware kompatibel ist,
- dass sie automatisch installiert werden sollte,
- dass sie ein eigenes Paketformat benötigt.
Es bedeutet im Kern:
Die Software ist eine optionale Ergänzung zum regulären Slackware-Paketsatz.
Fazit
Das extra/-Konzept ist ein kleines, aber sehr aussagekräftiges Beispiel dafür, wie Slackware seine gesamte Distribution strukturiert.
Slackware trennt bewusst zwischen:
Was gehört zum System?
und:
Was ist zusätzlich nützlich?
Das Ergebnis ist:
Slackware64
│
┌────────────┴────────────┐
│ │
regulär extra
│ │
slackware64/ optionale Pakete
│ │
patches/ offiziell bereitgestellt
│ │
└────────────┬────────────┘
│
System nach Bedarf
extra/ ist damit kein zweites, inoffizielles Slackware-Repository, sondern eine bewusst getrennte Schicht innerhalb der offiziellen Slackware-Distribution.
Die eigentliche Stärke des Konzepts liegt in seiner Einfachheit:
Slackware kann zusätzliche Software anbieten, ohne sie jedem Benutzer aufzuzwingen.
Genau darin zeigt sich die größere Philosophie der Distribution: Das Basissystem soll klar definiert und überschaubar bleiben, während der Administrator es bewusst und nachvollziehbar erweitern kann.
Für Slackware64 15.0 ist diese Struktur weiterhin praktisch relevant. Das offizielle Repository führt extra/ auch 2026 als eigenständigen, mit eigenen Paketmetadaten ausgestatteten Bereich; gleichzeitig werden patches/, source/, testing/ und pasture/ getrennt geführt.
Wer Slackware wirklich verstehen möchte, sollte extra/ deshalb nicht nur als Verzeichnis voller zusätzlicher .txz-Dateien betrachten. Es ist vielmehr ein Ausdruck des grundlegenden Slackware-Entwurfs: ein bewusst kleines Fundament, das der Administrator mit klar abgegrenzten Bausteinen erweitern kann.