dpkg ist so geil

[RobertDebiannutzer]

Durch die ganzen apt vs. apt-get vs. aptitude vs. sonstwas geht ganz unter, was dpkg alles kann.
Das ist mir aufgefallen, weil ich gerade ein Script schreibe, bei dem dpkg beteiligt ist.
Bisher hatte ich mit dpkg nur in Form von "dpkg -i" und "dpkg -l" zu tun.
Doch nun brauchte ich zwei Listen der installierten Pakete. Einmal in der Form 1. Spalte = [Source-Paketname] und 2. Spalte = [Paketname] und einmal in der Form 1. Spalte = [Paketname] und 2. Spalte = [Version].
Erst habe ich das mühsam mit wget und sed (1. Liste) gemacht bzw. mit "dpkg -l" und sed (2. Liste).
Doch dann habe ich gesehen was dpkg kann und brauche jetzt für die 1. Liste nur noch:

Code: Alles auswählen

dpkg-query -W -f='${source:Package} ${binary:Package}\n'

und für die 2. Liste das hier:

Code: Alles auswählen

dpkg-query -W -f='${binary:Package} ${Version}\n'

Man muss echt häufiger mal schauen, was dpkg so bietet!

Code: Alles auswählen

apropos '^dpkg-.*'

Übrigens ist "dpkg -s" oder "dpkg-query -s" wesentlich schneller als "apt show" oder "aptitude show". Je nachdem, welche Informationen man haben möchte, kann dpkg also auch in dieser Verwendung wirklich von Vorteil sein.

[inne]

Das dpkg-query -W -f='${source:Package}\n' | sort -u | wc -l, um sich die Anzahl installierter Pakete in Quellpakten auszugeben hat was... wäre was für die Fortune Debian Tipps.

Ich hatte so etwas mal gesucht

[Meillo]

Was dpkg nicht kann, ist Abhaengigkeiten aufzuloesen und was sonst noch mit Abhaengigkeiten zu tun hat, wie Upgradepfade zu finden und so. Das ist der Grund, warum es apt-get und Co. ueberhaupt gibt. Strukturell koennten apt-get und Co. im Backend dpkg nutzen (werden sie aus Performancegruenden wohl nicht tun).

[RobertDebiannutzer]

Ja klar, wenn ich oben schrieb, dass ich "dpkg -i" nutze, dann meinte ich damit nur in den Ausnahmefällen, in denen ich ein lokales Paket installiere. D.h., wenn ich z.B. ein Paket sauber lokal gebackported habe.*
Wobei es bei apt glaube ich mittlerweile auch eine Möglichkeit gibt, lokale .debs zu installieren.

Strukturell koennten apt-get und Co. im Backend dpkg nutzen

In der Debian Wiki-Page zu apt steht, dass

APT resolves dependency problems and retrieves requested packages from designated package repositories. APT delegates the actual installation and removal of packages to dpkg.

*Wenn ich normal Pakete installiere/entferne/upgrade, nutze ich "apt-get" fürs upgrade, "apt" nehme ich fürs update der Datenbank und zum installieren/purgen, wenn ich dazu nicht aptitude zu nutzen, was ich aber meistens mache.

[Meillo]

Strukturell koennten apt-get und Co. im Backend dpkg nutzen

In der Debian Wiki-Page zu apt steht, dass

APT resolves dependency problems and retrieves requested packages from designated package repositories. APT delegates the actual installation and removal of packages to dpkg.

Aha, sehr schoen!

[guennid]

Strukturell koennten apt-get und Co. im Backend dpkg nutzen (werden sie aus Performancegruenden wohl nicht tun)

Die Zusammenhänge habe ich bisher immer völlig anders verstanden. apt&Co benutzen definitiv dpkg, sind nichts anderes als frontends für dpkg.

[TRex]

Prinzipiell lässt sich das vermutlich verallgemeinern: "ffmpeg ist so geil", "git ist so geil"... wenn man Interesse (bzw Bedarf) an den low-level Tools hat und die Frontends einen anderen Fokus als die eigentliche Aufgabenstellung haben oder die Komplexität nicht abbilden.

[KBDCALLS]

Man sollte sich aber auch mit dpkg selbst befassen. Es kann zumindest nicht schaden wenn mans tut. Denn irgendwann stoßen alle an iihre Grenzen. Ob jetzt apt oder aptitude oder für die Mausschubser kpackage und wie sie alle heißen.

[Meillo]

Strukturell koennten apt-get und Co. im Backend dpkg nutzen (werden sie aus Performancegruenden wohl nicht tun)

Die Zusammenhänge habe ich bisher immer völlig anders verstanden. apt&Co benutzen definitiv dpkg, sind nichts anderes als frontends für dpkg.

Ist ja auch sehr schoen, dass das so ist. Meine Vermutung war nur gepraegt von dem was ich inzwischen leider viel zu oft sehen muss: Man implementiert die gleiche Funktionalitaet erneut intern, aus Performancegruenden, statt vorhandene Programme zu nutzen. Inzwischen gehe ich -- wie man gemerkt hat -- schon davon aus, dass das der Normalfall ist. Dass es hier doch nicht so ist, sondern so ist, wie es sein sollte, finde ich grossartig.