(gelöst) dpkg -l | grep dmo

[guennid]

Naive Frage (ich weiß es schlicht nicht): zeigt mir ein

Code: Alles auswählen

dpkg -l | grep dmo

alles, was das Paketmanagement an Paketen von deb-multimedia kennt? (Ob's noch mehr zeigt, interessiert mich einstweilen nicht, nur weniger sähe ich nicht so gerne.)

Grüße, Günther

[hikaru]

Was dein Kommando macht ist, alle installierten Pakete aufzulisten, die "dmo" im Namen haben.
Deine Frage lässt sich also umformulieren in: 'Tragen alle Pakete von dmo auch "dmo" im Paketnamen?'

Überprüfen wir das exemplarisch für Buster/amd64! [1]

Code: Alles auswählen

$ egrep '^Version' /tmp/Packages | grep -v dmo
Version: 2016.8.1
Version: 0.9.9.6+20190930-0.1+deb10u1
Version: 0.9.9.6+20190930-0.1+deb10u1
Version: 35.0.0-0.0
Version: 35.0.0-0.0
Version: 2.6.3-1

Das erste ist deb-multimedia-keyring.
Nr. 2 und 3 sind libglm-dev und libglm-doc.
Nr. 4 und 5 sind mkvtoolnix und mkvtoolnix-gui.
Nr. 6 ist python3-setupmeta.

Antwort:
Diese sechs Pakete wird dir dein Kommando nicht anzeigen, wenn sie installiert sind. Es wäre auch zu schön gewesen, wenn es so einfach wäre.


[1] ftp://ftp.deb-multimedia.org/dists/bust ... ackages.gz

[MaGe]

Code: Alles auswählen

 dpkg -l | grep dmo

106 dateien
da die dateien "dmo" im vergleich neuer sind

Code: Alles auswählen

 apt-show-versions | grep "dmo" 

106 dateien


gruss MaGe

[guennid]

Deine Frage lässt sich also umformulieren in: 'Tragen alle Pakete von dmo auch "dmo" im Paketnamen?

Das hatte ich in der Tat vorausgesetzt/erwartet.

Hmmm,
Nach shell-Syntax frag ich hier im df nicht gerne. Da müsste der Antwortende meiner Meinung nach für Ahnungslose wie mich zeichenweise formulieren und das sollte man niemandem zumuten. Man macht auch den Antwortenden leicht ungehalten.

Ansonsten bedank' ich mich erstmal für die Nachdenk-Anregung!

[willy4711]

Das erste ist deb-multimedia-keyring. ----> Stimmt

Nr. 2 und 3 sind libglm-dev und libglm-doc. ------> Stimmt

Nr. 4 und 5 sind mkvtoolnix und mkvtoolnix-gui. -----> Stimmt nicht zumindest in Testing :

Code: Alles auswählen

apt-cache policy mkvtoolnix*
mkvtoolnix:
  Installiert:           40.0.0-1
  Installationskandidat: 40.0.0-1
  Versionstabelle:
 *** 40.0.0-1 500
        500 http://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status
mkvtoolnix-gui:
  Installiert:           40.0.0-1
  Installationskandidat: 40.0.0-1
  Versionstabelle:
 *** 40.0.0-1 500
        500 http://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status

Nr. 6 ist python3-setupmeta. ----> Stimmt

Also auch nicht vollständig wahr

[hikaru]

Nach shell-Syntax frag ich hier im df nicht gerne. Da müsste der Antwortende meiner Meinung nach für Ahnungslose wie mich zeichenweise formulieren und das sollte man niemandem zumuten. Man macht auch den Antwortenden leicht ungehalten.

Willst du damit sagen, dass du meine grep-Pipe nicht verstehst? Du bist ja däm...

Nein, Scherz beiseite. In dem verlinkten Archiv steckt eine Textdatei, in der alle auf dmo gehosteten Pakete für Buster/amd64 inklusive Versionsnummern stehen.
Mein erstes grep (egrep) sucht nun alle Versionsnummernzeilen aus dieser Datei (Regex: Zeile fängt mit "Version" an). Diesen Output stecke ich in das zweite Kommando, welches alle Versionsnummern wegschmeißt, die "dmo" enthalten ("-v" = Zeige alles ohne den angegebenen String). Übrig bleiben also alle Versionsnummern, die kein "dmo" enthalten.
Nun könnte man noch ein Script drumherum stricken, das mit dieser Liste wieder die Paketnamen aus der Datei sucht, aber bei nur sechs Paketen habe ich das per Hand gemacht.

Nr. 4 und 5 sind mkvtoolnix und mkvtoolnix-gui. -----> Stimmt nicht zumindest in Testing :

Code: Alles auswählen

apt-cache policy mkvtoolnix*
mkvtoolnix:
  Installiert:           40.0.0-1
  Installationskandidat: 40.0.0-1
  Versionstabelle:
 *** 40.0.0-1 500
        500 http://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status
mkvtoolnix-gui:
  Installiert:           40.0.0-1
  Installationskandidat: 40.0.0-1
  Versionstabelle:
 *** 40.0.0-1 500
        500 http://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status

Was ist dein Punkt? In Buster liegt Version 35 vor, in Bullseye offenbar Version 40. Mein Punkt ist, dass der Versionsstring kein "dmo" enthält und also von guennids Kommando nicht gefunden wird.
Deiner Ausgabe nach hat sich das in Bullseye nicht geändert. Aber selbst wenn es das getan hätte, wäre in Buster immer noch eine Version ohne "dmo" vorhanden. Mein Punkt ist, dass die Suche nach "dmo" in der Paketversion nicht geeignet ist, um dmo-Pakete ohne False Negatives zu erkennen. Das demonstriert allein schon der vermutlich bei jedem dmo-Nutzer installierte Keyring.

[guennid]

Hmm, vermutlich kann ich dir folgen.
Also das Spielchen bis zum Ende durchgezogen, also bis zu „Paketnamen aus der Datei suchen“, sagte dann immer noch nichts darüber aus, woher das real installierte Paket denn nun tatsächlich stammt, wenn's zufällig im Debian Repo dasselbe gäbe - richtig?
Bei *toolnix* könnte das der Fall sein, wenn ich recht sehe.
So und jetzt zwei der Fragen, mit denen man sich schnell Ärger einhandelt:
1. Das „^“ heißt soviel wie: Suche das, was unmittelbar hinter mir kommt nur am Zeilenfang - richtig?
2. Im vorliegenden Beispiel wären die '' vor und hinter dem String: Version entbehrlich gewesen - richtig?

[willy4711]

Nr. 4 und 5 sind mkvtoolnix und mkvtoolnix-gui. -----> Stimmt nicht zumindest in Testing :

In deb.multimedia gibt es in Testing kein mkvtoolnix, weil es in die Debian-Repos gewandert ist.

Wenn wirklich noch was von dmo da sein sollte kann man auch noch mit

Code: Alles auswählen

apt-show-versions | grep newer

oder mit

Code: Alles auswählen

apt-show-versions |grep "No available"

Forschen gehen

Die Tatsachen das es in beiden Repos ein Paket mit gleicher Versionsnummer ohne Zusatz gibt, dürfte höchst selten sein (6X !).
Außerdem glaube ich nicht, dass in diesem Spezialfall Abhängigkeitsprobleme auftreten würden.

[hikaru]

Also das Spielchen bis zum Ende durchgezogen, also bis zu „Paketnamen aus der Datei suchen“, sagte dann immer noch nichts darüber aus, woher das real installierte Paket denn nun tatsächlich stammt, wenn's zufällig im Debian Repo dasselbe gäbe - richtig?

Richtig. Aber dazu, die Quelle eines Pakets zu bestimmen, taugt das Durchsuchen der Packages-Datei einer Quelle ohnehin nicht, denn es könnten mehrere Quellen den gleichen Paketnamen mit der gleichen Paketversion ausliefern.

1. Das „^“ heißt soviel wie: Suche das, was unmittelbar hinter mir kommt nur am Zeilenfang - richtig?

In dem Fall, ja. Regex ist hier syntaktisch leider etwas unglücklich. "^" kann nämlich an anderer Stelle auch eine Negation einleiten. Das ist hier leider kontextabhängig und man muss den Kontext verstehen um die Syntax zu verstehen.

2. Im vorliegenden Beispiel wären die '' vor und hinter dem String: Version entbehrlich gewesen - richtig?

Ja, denn hier gibt es keine Whitespaces im Suchmuster. Das habe ich in der Praxis bei der Verwendung von egrep (grep -E) allerdings so selten, dass ich automatisch Anführungszeichen setze, wenn ich egrep aufrufe.

In deb.multimedia gibt es in Testing kein mkvtoolnix, weil es in die Debian-Repos gewandert ist.

Meine Demonstration bezog sich auf Buster.

Die Tatsachen das es in beiden Repos ein Paket mit gleicher Versionsnummer ohne Zusatz gibt, dürfte höchst selten sein (6X !).
Außerdem glaube ich nicht, dass in diesem Spezialfall Abhängigkeitsprobleme auftreten würden.

Was selten sein dürfte und was nicht, oder was irgendwer von uns glaubt ist hier relativ unerheblich.
guennid möchte gern beliebige dmo-Pakete identifizieren. Dazu braucht er zunächst einmal eine Liste potenzieller Kandidaten, OHNE False Negatives. Wie demonstriert, ist das über den Weg der Paketversion nicht zu machen.

Übrigens braucht man auch keine Versionsgleichheit um Kompatibilitätsprobleme zu verursachen. Linux Mint hat z.B. über mehrere Releases hinweg bis Version 18 ein Paket "mdm" (Mint Display Manager") ausgeliefert, aktuell in Version "2.0.19+sylvia".
Dumm nur, dass mdm ("The Middleman System") eigentlich etwas ganz anderes ist, auch in Ubuntu. In Ubuntu 16.04, worauf Mint 18 basiert, liegt das echte mdm-Paket in Version "0.1.3-2.1build1" vor. Wer also auf Mint 18 "The Middleman System" brauchte, war ziemlich gekniffen.

[guennid]

Hach!!! Wieder was gelernt!

was irgendwer von uns glaubt ist hier relativ unerheblich.

Meine DMO-Praxis: Grundsätzlich auskommentieren in der sources.list. Genau anschauen, was beim gezielten Installieren passieren würde. Und aus dem hier Gelernten ziehe ich den Schluss, alles was installiert wird, dokumentieren und sich nicht auf dpkg -l verlassen. Auch das macht die Sache wohl nicht 100%ig sicher. Aber in meinem Leben meine ich gelernt zu haben, dass es 100% Sicherheit nicht gibt, nirgends, und wer's doch glaubt, wird früher oder später eines Besseren belehrt - sofern er sich belehren lässt. Pinning beherrsch' ich nicht, mach' ich nicht und ... siehe oben!

[willy4711]

Was selten sein dürfte und was nicht, oder was irgendwer von uns glaubt ist hier relativ unerheblich.

Nö ist es nicht.
Sicher kann man es so machen wie du vorgeschlagen hast. Geht aber genauso gut oder schlecht über
dpkg / apt-show-versions ohne was extra runter zu laden.

Du bist auch nicht der Hergott, der alles andere nicht gelten lässt, und lächerlich macht.
Ein ganz klein bisschen Erfahrung hab ich auch schon gesammelt.

Übrigens braucht man auch keine Versionsgleichheit um Kompatibilitätsprobleme zu verursachen. Linux Mint hat z.B. über mehrere Releases hinweg bis Version 18 ein Paket "mdm" (Mint Display Manager") ausgeliefert, aktuell in Version "2.0.19+sylvia".
Dumm nur, dass Debianmdm ("The Middleman System") eigentlich etwas ganz anderes ist, auch in Ubuntu. In Ubuntu 16.04, worauf Mint 18 basiert, liegt das echte mdm-Paket in Version "0.1.3-2.1build1" vor. Wer also auf Mint 18 "The Middleman System" brauchte, war ziemlich gekniffen.

Musst nicht immer was an den Haaren herbei ziehen, um irgendwas zu beweisen was nicht existiert.
Wir reden - glaube ich jedenfalls - über Debian und ein Debian sehr nahe stehendes Repo.
Und da vertraue ich - bei Namens und Versionsgleichheit - beiden.