Größe des Debian Archives

[schorsch_76]

Vielleicht 'ne dumme Frage (Haben wir heute unter den Kollegen diskutiert): Wie groß ist eigentlich das Debian (stable) Archiv mittlerweile wenn man alles runter laden würde? Sagen wir mal amd64 und wie groß insgesamt?

[MSfree]

Ich kann dir nicht sagen, wir groß Bookworm/x64 ist. Mein Debian Mirror spiegelt x64 und i386 jeweils für Buster, Bullseye, Bookworm, Trixie und SID. Der belegt im Moment rund ein TB. Nach Adam Milchmädchen sind das also rund 100GB pro Architektur und Distribution. Milchmädchen deshalb, weil es einige architekturunabhängige Pakete gibt und auch deshalb, weil das Archiv mit jedem Release umfangreicher wird. Man sollte also für Bookworm/x64 mindestens mit 120GB kalkulieren.

[JTH]

Unter https://www.debian.org/mirror/size findet man die Größen der einzelnen Architekturen auf einem Mirror. Nach Release ist die Tabelle leider nicht unterteilt.

[schorsch_76]

Danke für die Info

[hikaru]

Ich kann dir nicht sagen, wir groß Bookworm/x64 ist. Mein Debian Mirror spiegelt x64 und i386 jeweils für Buster, Bullseye, Bookworm, Trixie und SID. Der belegt im Moment rund ein TB. Nach Adam Milchmädchen sind das also rund 100GB pro Architektur und Distribution.

Das kommt hin:

Code: Alles auswählen

$ wget -q -O - http://ftp.de.debian.org/debian/dists/Debian12.2/main/binary-amd64/Packages.gz | gzip -cd | egrep '^Size:' | cut -c 6- | awk '{ sum += $1 } END { print sum }'
9,42465e+10

[wanne]

So ganz auseinander drösenl kann man es IMHO gar nicht mehr, da die Pakete ja mittlerweile alle in pool liegen und entsprechend oft für mehrere Architekturen und Releases gültig sind.

[uname]

@hikaru
Müsste man nicht auch noch für contrib, non-free und non-free-firmware schauen? Ich weiß auch nicht, ob man sich mal eine Standard-Installation anschauen kann, um abzuschätzen, wie viele Pakete in etwa nicht abhängig von der Architektur wie z. B. amd64 sind.

[hikaru]

Müsste man nicht auch noch für contrib, non-free und non-free-firmware schauen?

Ja.

Ich weiß auch nicht, ob man sich mal eine Standard-Installation anschauen kann, um abzuschätzen, wie viele Pakete in etwa nicht abhängig von der Architektur wie z. B. amd64 sind.

Für architekturunabhängige Pakete gibt es die Pseudo-Architektur "all".
Da muss man halt vorher definieren, welche Größe einen interessiert, und dann die passende Kombination aus Architekturen und Zweigen wählen. Mein Einzeiler war nur ein "Proof of Concept" um zu zeigen, dass sich die genaue Größe des Archivs durchaus ermitteln lässt.

all/main schlägt mit rund 60GB zu Buche :

Code: Alles auswählen

$ wget -q -O - http://ftp.de.debian.org/debian/dists/Debian12.2/main/binary-all/Packages.gz | gzip -cd | egrep '^Size:' | cut -c 6- | awk '{ sum += $1 } END { print sum }'
59401504076

Der Rest dessen was für amd64 relevant ist, kommt insgesamt auf ca. 13GB.

[uname]

Danke. Wo du dabei bist, könntest du eben noch die Anzahl der Pakete ausgeben. Laut hier sind es über 59.000 Pakete.

[hikaru]

"Über 59000" stimmt, ist aber etwas tiefgestapelt:

Code: Alles auswählen

$ wget -q -O - http://ftp.de.debian.org/debian/dists/Debian12.2/main/binary-amd64/Packages.gz | gzip -cd | egrep '^Size:' | wc -l
63352

Selbes Prinzip: Für weitere Architekturen/Zweige gelten eigene Werte.

[wanne]

Der Rest dessen was für amd64 relevant ist, kommt insgesamt auf ca. 13GB.

Wie komsmt du darauf?
amd64 kommt auf 88GiB. All auf 55GiB. Aach Adam Riese müssten der Unterschied also ~33GiB sein?

Danke. Wo du dabei bist, könntest du eben noch die Anzahl der Pakete ausgeben. Laut hier sind es über 59.000 Pakete.

Code: Alles auswählen

wget -q -O - http://ftp.de.debian.org/debian/dists/bookworm/main/binary-amd64/Packages.gz | gzip -cd | egrep '^Package: ' | wc -l
63352
wget -q -O - http://ftp.de.debian.org/debian/dists/bookworm/main/binary-amd64/Packages.gz | gzip -cd | egrep '^Package: ' | wc -l
63352

Das enthöllt aber keine updates (30MiB) und securitiy-updates (14GiB). (Enthält immer nur die neusten Updates für AMD64. Zwischenversionen werden leider nicht aufgehoben.)
i386 schlägt btw mit 62577 Paketen und 85GiB zu buche. => Es gibt jetzt mehr Pakete, die nicht in 32Bit verfügbar sind als welche, die nicht in 64Bit verfügbar sind. Und das obwohl viele 32Bit Pakete nur eh schon 64Bit (wie pae oder SSE) Funktionalität nachliefern. Sind wohl in erster Linie Emulatoren, Datenbanken und ein paar HPC/Bioinf-Libs. Fürs 32Bit zeug vor allem irgend welches steinaltes Multimedia zeug.

[wanne]

Hier eine bereinigte Liste: pastebin/?mode=view&s=42023
Btw: Kann jemand die dämliche Dateiendungserweiterungsbeschränkung weg machen? In einem Linux Forum ist das reichlich absurd, dass du dir Dateiendungen aussuchen musst, die auch Windows kennt.

[Cordess]

Unter https://www.debian.org/mirror/size findet man die Größen der einzelnen Architekturen auf einem Mirror. Nach Release ist die Tabelle leider nicht unterteilt.

Hier wäre es schön, wenn es für jede Architektur eine Minimaledition geben würde, die so minimal ist, dass man, sobald man die 111 GiB Quellcode dazu nimmt, alles wieder aus allein dem Quellcode bauen kann.

So müsste man nur die Minimaledition und die 111 GiB an Quellcode für schlechte Zeiten, wie bspw. ein Atomkrieg, archivieren.
Die Netinstaller Edition dürfte dafür nicht genügen, denn die lädt bei der Installation Pakete ja lediglich nur nach und somit auch den C Compiler.

[hikaru]

Der Rest dessen was für amd64 relevant ist, kommt insgesamt auf ca. 13GB.

Wie komsmt du darauf?
amd64 kommt auf 88GiB. All auf 55GiB. Aach Adam Riese müssten der Unterschied also ~33GiB sein?

Die 88 und die 55GiB sind beide für amd64 relevant. Die addieren sich also.
Auf die zusätzlichen 13GB kam ich überschlägig, wenn ich jeweils für contrib, non-free und non-free-firmware amd64 und all zusammengezählt habe.

Das enthöllt aber keine updates (30MiB) und securitiy-updates (14GiB).

Richtig. Das jeweils aktuellste Update eines Pakets ersetzt alle vorherigen Versionen und macht sie damit irrelevant für das laufende System. (Als Betreiber eines Repos kann man das anders sehen.)
Updates erzeugen meist sehr geringe Differenzen in den Paketgrößen. Ich habe es nicht geprüft, würde hier aber argumentieren, dass diese Differenzen vernachlässigbar sind.

Generell geht es mir hier nicht um's einzelne GB, ja noch nicht mal um 10GB, sondern nur um die Größenordnung. Ich wollte lediglich einen Weg aufzeigen, wie sich MSfrees Schuss aus der Hüfte objektivieren lässt.

[wanne]

Die 88 und die 55GiB sind beide für amd64 relevant. Die addieren sich also.

Ja. Aber du zählst doppelt. Da "Architecture: all" üblicherweise auch für amd64 benötigt wird sind alle 31102 Pakete eben auch in der binary-amd64/Packages.gz (Da amd64 Systeme per default binary-all/Packages.gz nicht lesen. Das enthält btw sogar fenix-dev also header Dateien für ein Programm, das selbst gar nicht unter amd64 läuft. (Man kann die aber natürlich zum cross compilieren nutzen – muss dann aber auf einem i368 System linken und ausführen.) Sie linken aber eben immer auf die gleiche Datei in Pool.

Updates erzeugen meist sehr geringe Differenzen in den Paketgrößen.

Aber Debian liefert (im Gegensatz zu Fedora) keine diffs aus und der Installer will die Originalpakete. Deswegen heben die Mirrors immer das erste und das letzte Paket auf und schmeißen die Zwischenversionen weg.

[Cordess]

Updates erzeugen meist sehr geringe Differenzen in den Paketgrößen.

Aber Debian liefert (im Gegensatz zu Fedora) keine diffs aus und der Installer will die Originalpakete. Deswegen heben die Mirrors immer das erste und das letzte Paket auf und schmeißen die Zwischenversionen weg.

Und das ist sehr ärgerlich, denn neulich hätte ich eine Zwischenversion benötigt, weil die neuere Version kaputt war, und sie ließ sich nicht installieren.

[wanne]

Ja. Hat mich auch schon geärgert.

[hikaru]

Ja. Aber du zählst doppelt. Da "Architecture: all" üblicherweise auch für amd64 benötigt wird sind alle 31102 Pakete eben auch in der binary-amd64/Packages.gz (Da amd64 Systeme per default binary-all/Packages.gz nicht lesen.

Das war mir nicht bekannt. Danke!

Aber Debian liefert (im Gegensatz zu Fedora) keine diffs aus und der Installer will die Originalpakete. Deswegen heben die Mirrors immer das erste und das letzte Paket auf und schmeißen die Zwischenversionen weg.

Ich weiß. Mir ging es um die Gesamtgröße aller theoretisch installierbaren Pakete. Und dabei ist am Ende nur das letzte Update enthalten, nicht das ursprüngliche Paket.

neulich hätte ich eine Zwischenversion benötigt, weil die neuere Version kaputt war, und sie ließ sich nicht installieren.

In dem Fall kannst du auf die Snapshots [1] zurückgreifen und das Paket auf "hold" setzen. Das ist eine hässliche Lösung, aber sie funktioniert.

[1] http://snapshot.debian.org/

[Cordess]

neulich hätte ich eine Zwischenversion benötigt, weil die neuere Version kaputt war, und sie ließ sich nicht installieren.

In dem Fall kannst du auf die Snapshots [1] zurückgreifen und das Paket auf "hold" setzen. Das ist eine hässliche Lösung, aber sie funktioniert.

[1] http://snapshot.debian.org/

Danke für den Tipp. Das werde ich dann mal ausprobieren.