Abhängigkeitspfade zu systemd und mögliche Alternativen

[JTH]

ähm, ja, ähm *schnell-hinter-dem-nächsten-Baum-versteck*

Hinter dem Abhängigkeitsbaum von geeqie? Den kann man von der Rückseite bestimmt noch besser analysieren!

[eggy]

[Meillo]

Btw: Ich weiss jetzt warum die Ausgabe so durcheinander war: Das `tac' darf nur auf oberster Ebene angewendet werden und nicht auf jeder Rekursionsstufe. Es waere einfacher wenn du nicht das ganze Script erneut aufrufen wuerdest, sondern den Code in eine Shellfunktion packst und nur diese rekursiv nutzt. Dann kannst du naemlich hinter den ersten Aufruf ein `|tac' setzen.

Keine Ahnung ob das generell so ist, aber Rekursion ist jedenfalls immer einfacher wenn man eine umgebende Funktion hat, die nur einmal laeuft und eine darin rekursierende Hilfsfunktion. In deinem Fall hast du nur genau ein einziges Script, das sich komplett selber aufruft. Das macht es unhandlicher.

Wenn man keine zwei Funktionen/Scripte haben kann/will, dann kann man sich auch damit behelfen, dass man durch eine Variable herausfindet, ob man auf der nullten Rekursionsstufe ist und nur dort irgendwelchen Zusatzcode ausfuehrt. Das ist aber schlecht lesbar und mehr eine Notloesung. Zwei Funktionen sind immer schoener:

Code: Alles auswählen

function doit() {
	...
	recurse(0)
	...
}

function recurse(n) {
	...
	recurse(n+1)
	...
}

[Meillo]

ähm, ja, ähm *schnell-hinter-dem-nächsten-Baum-versteck*

Hinter dem Abhängigkeitsbaum von geeqie? Den kann man von der Rückseite bestimmt noch besser analysieren!

eggy, JTH und ich in einem Thread ... das kann einfach nicht gut gehen.

[eggy]

Dann werd ich mich mal zurückziehen und Euch das Feld überlassen - für heute

... ich erwarte das fertige Script von Euch dann heute abend

[hikaru]

Wir wollten urspruenglich doch nur wissen *warum* bzw. *worueber* Systemd in die Abhaengigkeit gezogen wird.

fischig wollte außerdem wissen, ob es eine Möglichkeit gibt, Systemd zu umschiffen (die "Landschaftsroute" aus meinem letzten Beitrag). Das leistet bisher keine der präsentierten Lösungen.

Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz.

Doch, implizit. Im Prinzip wollen wir alle (und fischig im Besonderen) ein möglichst schlankes System. Die Gewichte in Form der Paketgrößen zu berücksichtigen wäre der algorithmische Ausdruck dieses Wunsches.

Das ist aber eine ganz andere Fragestellung.

Das ist mir zu akademisch. Es ist ein bisschen so, als würde ich dich fragen, ob du mir die Uhrzeit sagen kannst, und deine Antwort lautet: "Ja."
Natürlich wäre das die formal korrekte Antwort auf meine Frage. Aber eigentlich hätte ich erwartet, dass du mir die Uhrzeit sagst, auch wenn das streng genommen nicht meine Fragestellung war.

Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
[..]
D.h. die Ausgabe vor dem Rekursionsaufruf oder die Ausgabe nachdem er zurueckgekehrt ist.

Wie gesagt, ich habe bei der Ausgabe des Endpakets geschummelt, denn ich gebe es nicht innerhalb der Rekursion aus, weil diese damit beginnt, den vorherigen Knoten des Endpakets zu ermitteln. Daher ist es nicht trivial, innerhalb des Scripts die Ausgabe umzukehren.

(Ich kann's bloss nicht selber testen, weil ich kein geeignetes System zur Verfuegung habe.)

Alles was du brauchst ist ein debtree-Output:
41437

In deinem Fall hast du nur genau ein einziges Script, das sich komplett selber aufruft. Das macht es unhandlicher.

Ja. Das ganze Script ist im Grunde nur ein Wrapper um die grep-Zeile.

Wenn man keine zwei Funktionen/Scripte haben kann/will, dann kann man sich auch damit behelfen, dass man durch eine Variable herausfindet, ob man auf der nullten Rekursionsstufe ist und nur dort irgendwelchen Zusatzcode ausfuehrt.

Genau das mache ich bereits über die Anzahl der übergebenen Argumente um herauszufinden, ob ich neue Hilfsdateien anlegen muss oder die bereits erzeugten nutzen soll.

Ich glaube hier werden unsere unterschiedlichen Ansätze deutlich:
Ich bin Techniker. Ich will für ein gegebenes Problem eine möglichst einfache Lösung haben. "Einfach" bedeutet hier, so wenig Aufwand wie möglich in die Lösung zu investieren. Diese Lösung habe ich und die Reihenfolge die Ausgabe sowie die Eleganz des Codes sind für mich eher nebensächlich.
Du bist Akademiker. Du stebst eine "Schulbuchlösung" an, auch wenn das bedeutet, zusätzliche Arbeit in die Schönheit des Codes und der Ausgabe zu investieren. "Schönheit" in diesem Kontext ist oft nahe verwandt mit Zukunftssicherheit (Funktionen, vollständig rekursive Ausgabe).
Beide Ansätze haben ihre Berechtigung. Sieh meine Lösung als "Proof of Concept"!

... ich erwarte das fertige Script von Euch dann heute abend

Wie, heute Abend? Ich war der Ansicht, du präsentierst zur Mittagspause eine ordentliche Lösung.

[Meillo]

Wir wollten urspruenglich doch nur wissen *warum* bzw. *worueber* Systemd in die Abhaengigkeit gezogen wird.

fischig wollte außerdem wissen, ob es eine Möglichkeit gibt, Systemd zu umschiffen (die "Landschaftsroute" aus meinem letzten Beitrag). Das leistet bisher keine der präsentierten Lösungen.

Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz.

Doch, implizit. Im Prinzip wollen wir alle (und fischig im Besonderen) ein möglichst schlankes System. Die Gewichte in Form der Paketgrößen zu berücksichtigen wäre der algorithmische Ausdruck dieses Wunsches.

Das ist aber eine ganz andere Fragestellung.

Das ist mir zu akademisch. Es ist ein bisschen so, als würde ich dich fragen, ob du mir die Uhrzeit sagen kannst, und deine Antwort lautet: "Ja."
Natürlich wäre das die formal korrekte Antwort auf meine Frage. Aber eigentlich hätte ich erwartet, dass du mir die Uhrzeit sagst, auch wenn das streng genommen nicht meine Fragestellung war.

Lustig, weil ich wuerde sagen, dass das pragmatisch ist: Divide and Conquer bzw. One tool, one job. Wer wuerde zwei so unterschiedliche Fragestellungen, auch wenn sie im gleichen Anwendungskontext aufkommen, in einem Aufwasch erschlagen wollen?

Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
[..]
D.h. die Ausgabe vor dem Rekursionsaufruf oder die Ausgabe nachdem er zurueckgekehrt ist.

Wie gesagt, ich habe bei der Ausgabe des Endpakets geschummelt, denn ich gebe es nicht innerhalb der Rekursion aus, weil diese damit beginnt, den vorherigen Knoten des Endpakets zu ermitteln. Daher ist es nicht trivial, innerhalb des Scripts die Ausgabe umzukehren.

[...]

In deinem Fall hast du nur genau ein einziges Script, das sich komplett selber aufruft. Das macht es unhandlicher.

Ja. Das ganze Script ist im Grunde nur ein Wrapper um die grep-Zeile.

Wenn man keine zwei Funktionen/Scripte haben kann/will, dann kann man sich auch damit behelfen, dass man durch eine Variable herausfindet, ob man auf der nullten Rekursionsstufe ist und nur dort irgendwelchen Zusatzcode ausfuehrt.

Genau das mache ich bereits über die Anzahl der übergebenen Argumente um herauszufinden, ob ich neue Hilfsdateien anlegen muss oder die bereits erzeugten nutzen soll.

Ich glaube hier werden unsere unterschiedlichen Ansätze deutlich:
Ich bin Techniker. Ich will für ein gegebenes Problem eine möglichst einfache Lösung haben. "Einfach" bedeutet hier, so wenig Aufwand wie möglich in die Lösung zu investieren. Diese Lösung habe ich und die Reihenfolge die Ausgabe sowie die Eleganz des Codes sind für mich eher nebensächlich.
Du bist Akademiker. Du stebst eine "Schulbuchlösung" an, auch wenn das bedeutet, zusätzliche Arbeit in die Schönheit des Codes und der Ausgabe zu investieren. "Schönheit" in diesem Kontext ist oft nahe verwandt mit Zukunftssicherheit (Funktionen, vollständig rekursive Ausgabe).
Beide Ansätze haben ihre Berechtigung. Sieh meine Lösung als "Proof of Concept"!

Ich glaube nicht, dass ich mich deiner Sichtweise anschliessen will. Ja, ich bin Akademiker und ich nutze dieses Wissen und diese Sichtweise um die vorliegenden Probleme und Wuensche zu analysieren und in diesem Zuge voran zu kommen. Ich strebe nicht zwangslaeufig Schulbuchloesungen an, aber ich nutze mein Schulbuchwissen um Loesungen zu finden ... die in dieser Betrachtungsweise oft einfacher zu finden werden.

Zugegeben, ich begnuege mich nicht damit, wenn irgendein Output kommt, sondern ich will ihn schon in der besten Form haben, wenn dafuer keine hoehere Komplexitaet noetig ist, sondern nur eine (mir durch mein akademisches Wissen ermoeglichte) Umarrangierung des Codes.

Dank des von dir geposteten Outputs konnte ich das nun selber testen. (Ich musste eine Anpassung machen, damit es auf FreeBSD lief: sed kennt normalerweise kein `\+', darum habe ich `.\+' durch das aequivalente `..*' ersetzt.)

Hier eine Umsetzung mit umgekehrter Ausgabe, die deinem Aufbau entspricht:

Code: Alles auswählen

#!/bin/sh

START=$1
END=$2

if [ $# -lt 3 ]
then
        DKS=${START}.dks
        debtree --no-alternatives $START 2>/dev/null > ${START}.dot
        dijkstra -dp $START ${START}.dot > $DKS
else
        DKS=$3
fi

egrep -A 1 "(\s|\")$END(\s|\").*\[dist" $DKS | tail -n 1 | sed 's/..*prev=//' | tr -d '",;]' | while read PKG
do
        if [ "$PKG" != "$START" ]
        then
                $0 $START $PKG $DKS
        fi
        echo $PKG
done

if [ $# -lt 3 ]
then
        echo $END
fi

(`echo $PKG' hinter der Rekursion und `echo $END' am Ende.)

Und hier eine Version mit Hilffunktion:

Code: Alles auswählen

#!/bin/sh

START=$1
END=$2
DKS=${START}.dks

recurse() {
        START=$1
        END=$2
        DKS=$3
        egrep -A 1 "(\s|\")$END(\s|\").*\[dist" $DKS | tail -n 1 | sed 's/..*prev=//' | tr -d '",;]' | while read PKG
        do
                if [ "$PKG" != "$START" ]
                then
                        recurse $START $PKG $DKS
                fi
                echo $PKG
        done
}

debtree --no-alternatives $START 2>/dev/null > ${START}.dot
dijkstra -dp $START ${START}.dot > $DKS
recurse $START $END $DKS
echo $END

Hier wird der Code IMO deutlich lesbarer. Das meinte ich mit dem Ansatz, dass man bei einer Rekursion immer zwei Funktionen hat, eine fuer die Rekursion selbst und eine (bzw. das Hauptprogramm) fuer das Drumherum. Das ist vermutlich immer einfacher als wenn der komplette Code rekursiert.

Man koennte sagen, dass mir hier mein akademisches Wissen hilft, die Sache klarer zu sehen ... dabei ist es hier aber gar kein akademisches Wissen (sondern nur akademisches Backgroundwissen), da mich das die Praxis gelehrt hat. (Akademisch ist nur an welcher Stelle man die Ausgabe machen muss, je nachdem in welcher Reihenfolge man sie haben will.)


Edit: Ich finde es nicht schlimm wenn nicht jeder dieses Wissen und diese Faehigkeiten hat. Mir selbst fehlen sie in theoretischen Bereichen oft genug selbst. (Dijkstra -- nie gehoert ... also den Algorithmus, denn die Person und seine Denkweisen kenne ich schon ganz gut. ) Dafuer haben wir ja zum Glueck andere Personen, die das beisteuern koennen was man selbst nicht so gut kann oder nicht so einfach sieht.

[hikaru]

Zugegeben, ich begnuege mich nicht damit, wenn irgendein Output kommt, sondern ich will ihn schon in der besten Form haben, wenn dafuer keine hoehere Komplexitaet noetig ist, sondern nur eine (mir durch mein akademisches Wissen ermoeglichte) Umarrangierung des Codes.

Irgendeinen Output wollte ich auch nicht haben. Die Sortierung sollte schon stimmen. Nur war es für mich eben gleichwertig ob sie Top-Down oder Bottom-Up ist.

Dank des von dir geposteten Outputs konnte ich das nun selber testen.

Am Rande:
Hier habe ich debtree mit --no-alternatives aufgerufen, was den Graphen deutlich vereinfacht. Nur deshalb funktioniert meine Lösung übrrhaupt, denn ich muss keine alterrnativen Verzweigungen beachten. Dadurch kann man aber schon prinzipilel aus der Eingabe keine alternativen Pfade mehr finden.

Hier eine Umsetzung mit umgekehrter Ausgabe, die deinem Aufbau entspricht:

Code: Alles auswählen

# ...
if [ $# -lt 3 ]
then
        echo $END
fi

Eben diese zusätzliche Abfrage der Anzahl der Argumente, welche ja schon mal am Anfang des Scripts gemacht wurde halte ich konzeptuell für extrem hässlich. Das war für mich ursprünglich der Grund, die Ausgabe nicht umzudrehen.

Und hier eine Version mit Hilffunktion:
[..]
Hier wird der Code IMO deutlich lesbarer.

Ja, das ist richtig. Aber das hässliche "echo $END" ganz am Ende gefällt mir immer noch nicht. Es ist gewissermaßen der in Kapstadt platzierte Elefant aus der "Elefantenjagd".

Man koennte sagen, dass mir hier mein akademisches Wissen hilft, die Sache klarer zu sehen ... dabei ist es hier aber gar kein akademisches Wissen (sondern nur akademisches Backgroundwissen), da mich das die Praxis gelehrt hat.

Ich denke es ist eher eine Frage der Herangehensweise.
Mein Script von gestern Abend war das evolutionäre Ergebnis eines längeren Prozesses, in dem ich zunächst probiert hatte, sowas Ähnlches wie den Dijkstra-Algorithmus nachzuprogrammieren, ohne mir dabei bewusst zu sein, dass es auf Dijkstra hinausläuft. Ich scheiterte aber immer an gewissen Typen von Abhängigkeiitsverzweigungen. Irgendwann stolperte ich bei meiner Recherche dann tatsächlich über Dijkstra und habe im Grunde nur mein bereits vorhandenes Script entkernt und die fertige Dijkstra-Lösung eingebaut. Als das funktionierte war die Aufgabe (Proof of Concept) für mich erledigt.
Was hier zu sehen ist, ist nur das Endergebnis. Und wenn das Parsen der dijkstra-Ausgabe nicht so kompliziert wäre, dann wäre der Rest kaum erwähnenswert. Im Grunde sollte das ein Schüler in der 10. Klasse hinkriegen.

[Meillo]

Natuerlich ist jede Umsetzung immer ein Zwischenstand auf einem Weg, gepraegt durch seine Vorgeschichte.


Hier nochmal eine Fortentwicklung:

Code: Alles auswählen

#!/bin/sh

START=$1
END=$2
DKS=${START}.dks

recurse() {
        echo $1
        test $1 = $START && return
        recurse $(sed -n '/[[:space:]"]'$1'[[:space:]"].*\[dist/ {n; s/[]",;]//g; s/.*prev=//p;}' $DKS)
}

debtree --no-alternatives $START 2>/dev/null > ${START}.dot
dijkstra -dp $START ${START}.dot > $DKS
recurse $END | tac

Ich gebe doch wieder am Anfang aus und drehe am Ende um, kann dafuer aber alles mit einem einzigen `echo' erledigen.

Die Pipeline um PKG zu finden habe ich zu einem einzigen sed-Aufruf umgebaut -- nur als Alternative, nicht weil es besser waere.

Die Schleife (die wohl anfangs fuer die alternativen Pfade vorgesehen war) habe ich entfernt und die Hilfsvariable $PKG dann auch ganz aufgeben koennen, nachdem ich nun mit $END (bzw. $1) vergleiche.

Das ist nun so ziemlich die Essenz des Algorithmus. Die Rekursionsfunktion enthaelt nur noch die drei esseziellen Bestandteile: Ausgabe, Abbruchbedingung, Rekursionsaufruf mit neuem Wert.


... Ja, dieser Post von mir ist akademisch motiviert.

Ohne deine Vorarbeit waere mir diese Vergnuegung nicht moeglich gewesen. Danke.

[Meillo]

Und hier als Bonus noch eine Variante, die die Ausgabe am Ende macht und folglich kein Umdrehen braucht:

Code: Alles auswählen

#!/bin/sh

START=$1
END=$2
DKS=${START}.dks

recurse() {
        if [ $1 != $START ]
        then
                recurse $(sed -n '/[[:space:]"]'$1'[[:space:]"].*\[dist/ {n; s/[]",;]//g; s/.*prev=//p;}' $DKS)
        fi
        echo $1
}

debtree --no-alternatives $START 2>/dev/null > ${START}.dot
dijkstra -dp $START ${START}.dot > $DKS
recurse $END

Das sollte dir doch nun gefallen, hikaru.

[hikaru]

Ich gebe doch wieder am Anfang aus und drehe am Ende um, kann dafuer aber alles mit einem einzigen `echo' erledigen.

Da frage ich mich halt aus zweierlei Gründen, ob das sinnvoll ist:
1. Ist ein tac vermutlich "teurer" als ein zweites echo.
2. Warum ist es überhaupt entscheidend, in welcher Richtung die Kette ausgegeben wird? Ich sehe da eigenlich nur den "historischen" Grund, dass ich in meienm ersten Beitrag so angefangen habe:

In Bullseye gibt es diesen Abhängigkeitspfad*: geeqie → libgtk-3-0 → libatk-bridge2.0-0 → libdbus-1-3 → libsystemd0.

Wenn ich das andersrum formuliert hätte, dann gäbe es diesen Teil der Diskussion vermutlich gar nicht. Ich finde es seltsam, wegen so einer Zufälligkeit die Lösung "teurer" zu machen.

Nachtrag:

Und hier als Bonus noch eine Variante, die die Ausgabe am Ende macht und folglich kein Umdrehen braucht:
[..]
Das sollte dir doch nun gefallen, hikaru.

Ja, sehr schön!

Die Pipeline um PKG zu finden habe ich zu einem einzigen sed-Aufruf umgebaut -- nur als Alternative, nicht weil es besser waere.

Sieht bei dir aber deutlich freundlicher aus.
Am Rande: Mir war bewusst, dass ich das tail -n 1 eigentlich nicht gebraucht habe, aber ich versuche gern, Inputs so minimalinvasiv wie möglich zu behandeln, denn das veringert die Gefahr, bei unerwarteten Eingaben unerwartete Ergebnisse zu bekommen.
Der gleiche Gedanke stand auch hinter der Idee, den Paketnamen mit einem Negativmatching zu extrahieren. Eigentlich ist wohldefiniert, welche Zeichen in einem Debianpaketnamen auftauchen dürfen, also wäre es eigentlich einfacher gewesen, darauf ein Positivmatching zu machen (insbesondere in Anbetracht der inkonsistenten dijkstra-Ausgabe).

Die Schleife (die wohl anfangs fuer die alternativen Pfade vorgesehen war) habe ich entfernt und die Hilfsvariable $PKG dann auch ganz aufgeben koennen, nachdem ich nun mit $END (bzw. $1) vergleiche.

Ja, das war der historische Grund für die Schleife. Ich hatte sie aber beibehalten, weil mir bei meinen späteren Tests in einigen Fällen untergekommen war, dass Pakete u.A. auch sich selbst als Abhängigkeit hatten. Ich vermute das waren virtuelle Pakete, aber ich habe es nicht weiter verfolgt. Die Schleife diente dann dazu, in solchen Fällen nicht in eine Sackgasse zu geraten.
In meinem ursprünglichen Ansatz brauchte ich außerdem eine Behandlung für zyklische Abhängigkeiten. Diese erledigt jetzt der dijkstra-Output.

[eggy]

@Meillo:

(Dijkstra -- nie gehoert ... also den Algorithmus, denn die Person und seine Denkweisen kenne ich schon ganz gut. )

https://algorithms.discrete.ma.tum.de/spp/

Die Graphenalgorithmen in der "Klasse", Dijkstra, A* (alternativer Name: A-Stern, AStar), Bellman-Ford und noch ne handvoll ähnlicher Ansaätze, sind fast alle sehr elegant/übersichtlich formuliert, an kleinen Beispiel gut nachzuvollziehen und daher auch recht einfach nachzuprogrammieren. Macht Spaß, also hat es mir jedenfalls damals™ gemacht, extrem gut sogar in dem Moment als ich meinen Denkfehler gefunden hatte und plötzlich alles lief wie gedacht.

Wie, heute Abend? Ich war der Ansicht, du präsentierst zur Mittagspause eine ordentliche Lösung.

Wenn ich nur etwas mehr Zeit hätte, würde ich liebend gerne mitspielen, leider passt es grad zeitlich nicht.

[Meillo]

Ich gebe doch wieder am Anfang aus und drehe am Ende um, kann dafuer aber alles mit einem einzigen `echo' erledigen.

Da frage ich mich halt aus zweierlei Gründen, ob das sinnvoll ist:
1. Ist ein tac vermutlich "teurer" als ein zweites echo.

Wie so oft war es ein Zwischenschritt auf dem Weg. Haette ich diesen gleich abgelehnt, dann waere ich gar nicht zu der nun letzten Variante gekommen. (Aber zugegeben, das ist hauptsaechlich ein akademisches/spielerisches/interessiertes Erkunden der Umsetzungsmoeglichkeiten.)

Allerdings, was genau meinst du mit ``teurer''? Bei Zeit- und Speicher-Performance ist das sicher so. Falls grosse Datenmengen zu erwarten waeren -- hier nicht der Fall -- dann waere das ein Grund. Bei der Code-Maintenance-Performance (die ich oft wichtiger finde) halte ich das `tac' fuer kostenguenstiger als das zweite `echo'. Da geht es um Robustheit und die Frage, was passiert wenn ich an einer Stelle im Code etwas aendere und andere Stellen nicht mitbedenke. Immer wenn eine Aufgabe dabei auf verschiedene Stellen aufgeteilt ist (wie zwei echos), birgt das die Gefahr, dass man nur eine anpasst und nicht beide. Wenn dagegen eine Aufgabe komplett an einer einzigen Stelle erledigt wird, kann das nicht passieren. (Diesen Gedanken finde ich zunehmend wichtiger wenn ich programmiere.)

2. Warum ist es überhaupt entscheidend, in welcher Richtung die Kette ausgegeben wird? Ich sehe da eigenlich nur den "historischen" Grund, dass ich in meienm ersten Beitrag so angefangen habe:

In Bullseye gibt es diesen Abhängigkeitspfad*: geeqie → libgtk-3-0 → libatk-bridge2.0-0 → libdbus-1-3 → libsystemd0.

Wenn ich das andersrum formuliert hätte, dann gäbe es diesen Teil der Diskussion vermutlich gar nicht. Ich finde es seltsam, wegen so einer Zufälligkeit die Lösung "teurer" zu machen.

Das kann so sein, ist es aber oft nicht. Meiner Meinung nach sind solche scheinbaren Nebensaechlichkeiten oft bedeutender als man meint. Hier war die Ausgangsfrage ja, woher die Systemd-Abhaengigkeit bei Geeqie kommt. Mir scheint es also stimimg zu sein, dass der Ausgangspunkt (geeqie) am Anfang steht und es dann immer tiefer geht. Auch sonst (z.B. auf der Debian-Paketseite) sind Abhaengigkeiten in der Richtung dargestellt: Am Anfang das Paket um das es geht und dann schrittweise tiefer dessen Abhaengigkeiten und wiederum deren, usw. Das scheint mir die in diesem Kontext uebliche und darum erwartete (vgl. POLS) Betrachtungsweise zu sein. (Edit: Auch kann man nur so rum sinnvoll Baeume, also mehrere Abhaengigkeiten oder Alternativen, darstellen. Darum macht man das wohl so rum.)


@eggy: A* hab ich schonmal gehoert. Im Studium hat mein Weg zufaellig drumrum gefuehrt. Und so Graphenprobleme habe ich selten bei meinen Programmierproblemen. Ich glaube ich koennte mich schon dafuer begeistern ... bloss begeistern mich andere Dinge mehr.

[fischig]

Wie ihr euch vielleicht denken könnt, habe ich den Code von Meillos Versuchen (noch) nicht verstanden, aber ich habe ihn schon mal in dieser Variante

Code: Alles auswählen

#!/bin/sh

START=$1
END=$2
DKS=${START}.dks

recurse() {
        echo $1
        test $1 = $START && return
        recurse $(sed -n '/[[:space:]"]'$1'[[:space:]"].*\[dist/ {n; s/[]",;]//g; s/.*prev=//p;}' $DKS)
}

debtree --no-alternatives $START 2>/dev/null > ${START}.dot
dijkstra -dp $START ${START}.dot > $DKS
recurse $END | tac

ausprobiert, indem ich das script mit den Parametern

Code: Alles auswählen

[script] geeqie systemd

gestartet habe. Außer der Meldung

Code: Alles auswählen

[script]: 9: test =: unexpected operator

wiederholt in mehreren tausend Zeilen habe ich nichts gesehen.

Liegt's daran, dass weder geeqie noch systemd installiert sind?

Eigentlich will ich etwas herausfinden, bevor „das Kind in den Brunnen gefallen ist“.

[hikaru]

Liegt's daran, dass weder geeqie noch systemd installiert sind?

Nein. Ob Pakete installiert sind oder nicht spielt hier keine Rolle. Es wird nur geprüft, ob sich aus dem debtree- bzw. dijksta-Output eine Kette bilden lässt.
Hier mal ein Beispiel aus einer VM, in der zwar Gnome und Mate installiert sind, aber nichts von LXDE:

Code: Alles auswählen

$ ./meillo.sh lxde lxsession
lxde
lxde-core
lxde-session
openbox-lxde-session
lxsession

Dazu muss allerdings gesagt werden, dass sowohl Meillos Variante als auch meine eine reine "Schönwetterlösung" ist. Sie funktioniert nur sauber, wenn es tatsächlich eine Abhängigkeitskette gibt.
Als Gegenbeispiel, es gibt keinen Pfad von abc zu def, ganz einfach, weil es die Pakete nicht gibt:

Code: Alles auswählen

$ ./meillo.sh abc def
./test.sh: 9: test: =: unexpected operator
# [999 weitere Zeilen]
./test.sh: 10: Maximum function recursion depth (1000) reached
# [1000 Leerzeilen]
def

Das ist offenbar das was du beobachtet hast. Mich verwundert das allerdings, denn geeqie und systemd gibt es ja.
Zumindest die "unexpected operator"-Meldungen wird man los, wenn man das $1 in Zeile 9 in Anführunszeichen setzt:

Code: Alles auswählen

test "$1" = $START && return

Erklären kann ich das momentan nicht. Meillo?

[Meillo]

Zumindest die "unexpected operator"-Meldungen wird man los, wenn man das $1 in Zeile 9 in Anführunszeichen setzt:

Code: Alles auswählen

test "$1" = $START && return

Erklären kann ich das momentan nicht. Meillo?

Korrekt. Das ist der Grund fuer die Meldung und die Loesung *dieser* Meldung.

Erklaerung: Ohne die Anfuehrungszeichen ersetzt die Shell hier $1 durch einen leeren String (also durch nichts), damit wird aus der Zeile dann:

Code: Alles auswählen

test  = wert-von-start && return

Das Test-Kommando kennt aber den Fall von nur zwei Argumenten bei denen das erste ein Gleichheitszeichen ist, nicht. Darum meckert es.

Anders ist es wenn Anfuehrungszeichen gesetzt sind, weil dann das Ergebnis nach der Ersetzung so aussieht:

Code: Alles auswählen

test "" = "wert-von-start" && return

Jetzt hat test *drei* Argumente bei denen das mittlere ein Gleichheitszeichen ist, und diesen Fall kennt test.

(*Warum* aber $1 ein leerer String ist, das habe ich jetzt nicht nachvollzogen. Ich wuerde schaetzen, dass es zuvor schon Fehlerausgaben gibt. Vielleicht ist deptree oder graphviz nicht installiert. Am besten die tatsaechlichen Ausgaben des Befehls posten. Wenn sie zu schnell vorbei scrollen, dann an den Aufruf noch ein `` 2>&1 | less '' anhaengen, dann kannst du sie sehen und kopieren.)

[hikaru]

Erklaerung: Ohne die Anfuehrungszeichen ersetzt die Shell hier $1 durch einen leeren String

Das war mir schon klar.

(*Warum* aber $1 ein leerer String ist, das habe ich jetzt nicht nachvollzogen.

Ich hatte gehofft, dass du hier direkt eine Antwort gehabt hättest.

Ich wuerde schaetzen, dass es zuvor schon Fehlerausgaben gibt.

Nein,. gab es nicht:

Code: Alles auswählen

$ ./meillo.sh abc def &> meillo.txt

41447


In /etc/debtree/endlist steht übrigens das:

Code: Alles auswählen

# This file is ignored when debtree is used to search for dependency paths
# between two packages.

Für mich impliziert das, dass debtree von allein solche Abhängigkeitsketten zwischen zwei Paketen ausgeben können sollte. Nur wird mir aus der Manpage nicht klar, wie das gehen soll. Weiß jemand mehr?

[Meillo]

Ach, jetzt verstehe ich worum es dir bei deiner Frage geht. Na, wenn es die Pakete nicht gibt oder sie keine Abhaengigkeiten haben, dann gibt es im Graphen auch keinen Pfad zwischen ihnen, folglich kann man (in der Implementierung mit sed) auch keinen naechsten bzw. vorigen Wert finden. Da kommt der leere Wert her: beim ersten rekursiven Aufruf, weil die Ausgabe des sed-Befehls leer ist.

Vermutlich sollte man die Ausgabe von debtree nach $END greppen, um zu sehen, ob wir ueberhaupt suchen muessen, oder ob gar kein Pfad zwischen den zwei Paketen vorhanden ist.

[JTH]

Für mich impliziert das, dass debtree von allein solche Abhängigkeitsketten zwischen zwei Paketen ausgeben können sollte. Nur wird mir aus der Manpage nicht klar, wie das gehen soll. Weiß jemand mehr?

Ja – gibt’s leider nicht mehr. Stattdessen wird auf aptitude why verwiesen.

Ich rufe an der Stelle mal dazu auf, immer alle, alle, alle Variablennutzungen zu quoten – außer man möchte explizit das Verhalten einer ungequoteten Variable haben. Es gibt viele Fälle, wo fehlende Quotes (wie hier) schädlich sind, keine, wo zu viel gesetzte Quotes schädlich sind, und wenige, wo man das Verhalten einer ungequoteten Variable haben möchte. (Meine Erfahrung.)

Ich habe am Wochenende auf zwei Zugfahrten nochmal weiter gebastelt. Es gibt von Graphviz ein awk-ähnliches Werkzeug, gvpr, das die Graphen wirklich „versteht“. Damit könnte man z.B. den einen sed-Aufruf ersetzen, der sich auf die gleichbleibende Formatierung des Graphquelltextes verlässt (Auszug):

Code: Alles auswählen

recurse() {
	if [ "$1" != "$START" ]; then
		recurse "$(gvpr -a "'$1'" 'N[$.name == ARGV[0]] { print($.prev); }' "$DKS")"
	fi
	echo "$1"
}

Oder man löst das Traversieren (sagt man das auch auf Deutsch?) des Pfads gleich ganz damit:

Code: Alles auswählen

#!/bin/bash

PKG=$1
DEP=$2

debtree \
	--endlist=<(echo "$DEP") \
	--no-alternatives \
	--no-skip \
	--quiet \
	--skiplist=/dev/null \
	"$PKG" |
dijkstra -dp "$PKG" |
gvpr -a "'$DEP'" '
BEG_G {
	$tvtype = TV_fwd;
	$tvroot = node($, ARGV[0]);
}

N[$.name == $tvroot.name] {
	print($.name);
	if ($.prev) {
		$tvroot = node($G, $.prev);
	}
}
' |
tac | tr "\n" " " | awk 'BEGIN { OFS=" -> "; } { $1=$1; print $0; }'

Man könnte auch den Pfad mit gvpr erst extrahieren und dabei „umdrehen“, dann könnte man das tac weglassen und ein Trennzeichen wie „->“ direkt mit gvpr ausgeben.

[Meillo]

Ich rufe an der Stelle mal dazu auf, immer alle, alle, alle Variablennutzungen zu quoten – außer man möchte explizit das Verhalten einer ungequoteten Variable haben. Es gibt viele Fälle, wo fehlende Quotes (wie hier) schädlich sind, keine, wo zu viel gesetzte Quotes schädlich sind, und wenige, wo man das Verhalten einer ungequoteten Variable haben möchte. (Meine Erfahrung.)

(Um mich rauszureden : Ich habe einfach hikarus Stil uebernommen, auch seine if-then-Formatierung und die geschweiften Klammern wo sie vor Punkt nicht noetig waren. Waehrend diese anderen Dinge jedoch nicht schaedlich sind, sind es die fehlenden Double-Quotes doch ... und insofern haette ich die nicht hinnehmen, sondern korrigieren sollten. )


Der Rest deines Posts ist auch toll. (Schoen zu sehen wie viel Potenzial dieses Thema und dieser Thead noch hat!)

[fischig]

Mir wär's ganz lieb, wenn meine dummen Anwenderanfragen nebenbei mitbeantwortet werden könnten , den code verstehen werde ich, wenn überhaupt, sowieso erst hinterher. Also: Müssen die als Parameter übergebenen Programme installiert sein? Aptitude nutze ich zwar auch nie, aber das zu installieren, wäre mir die Sache wert.

[Meillo]

Also: Müssen die als Parameter übergebenen Programme installiert sein?

Nein.

Du musst nur debtree und graphviz installieren, damit das Script funktioniert.

Zudem muessen die zwei als Parameter uebergebenen Programme auch tatsaechlich eine Abhaengigkeit haben, naemlich in der Richtung: Parameter1 haengt von Parameter2 ab. (Damit dieser Fall automatisch abgefangen wird und eine Fehlermeldung kommt muss das Script verbessert werden. Wenn du aber nur Parameter uebergibst, wo das der Fall ist, dann geht es.)

[hikaru]

Na, wenn es die Pakete nicht gibt oder sie keine Abhaengigkeiten haben, dann gibt es im Graphen auch keinen Pfad zwischen ihnen, folglich kann man (in der Implementierung mit sed) auch keinen naechsten bzw. vorigen Wert finden. Da kommt der leere Wert her: beim ersten rekursiven Aufruf, weil die Ausgabe des sed-Befehls leer ist.

Ok, das fängt dann bei mir (unabsichtlich) die while-Schleife ab.

Vermutlich sollte man die Ausgabe von debtree nach $END greppen, um zu sehen, ob wir ueberhaupt suchen muessen, oder ob gar kein Pfad zwischen den zwei Paketen vorhanden ist.

Man müsste den debtree-Output nach $START und $END greppen, bzw. schon vor dem Aufruf von debtree prüfen, ob es das Paket $START überhaupt gibt.
Aber selbst wenn beides positiv ist, ist damit immer noch nicht sichergestellt, dass es einen Pfad zwischen beiden gibt.

Ja – gibt’s leider nicht mehr. Stattdessen wird auf aptitude why verwiesen.

Die älteste auffindbare Version ist debtree 1.0 [1] und da gab es den Verweis auf aptitude auch schon. Schade, der ursprüngliche Code ist wohl verloren.

Ich rufe an der Stelle mal dazu auf, immer alle, alle, alle Variablennutzungen zu quoten

notiert

Ich habe am Wochenende auf zwei Zugfahrten nochmal weiter gebastelt. Es gibt von Graphviz ein awk-ähnliches Werkzeug, gvpr, das die Graphen wirklich „versteht“. Damit könnte man z.B. den einen sed-Aufruf ersetzen, der sich auf die gleichbleibende Formatierung des Graphquelltextes verlässt (Auszug):

gvpr sieht vielversprechend aus. Ich vermute, damit könnte man hier noch viel mehr machen, als einfach nur sed zu ersetzen (z.B. tatsächlich den/die Graphen von geeqie nach systemd extrahieren).
Dummerweise stehe ich mit awk (als Vorbild) auf Kriegsfuß und es gibt nicht viele gvpr-Beispiele im Netz. Ich hatte gehofft, "Extrahiere den Abschnitt von Knoten A bis Knoten B aus Graph G!" wäre eine leicht zu recherchierende Standardaufgabe.

(Um mich rauszureden : Ich habe einfach hikarus Stil uebernommen, auch seine if-then-Formatierung und die geschweiften Klammern wo sie vor Punkt nicht noetig waren. Waehrend diese anderen Dinge jedoch nicht schaedlich sind, sind es die fehlenden Double-Quotes doch ... und insofern haette ich die nicht hinnehmen, sondern korrigieren sollten. )

Zu meiner Verteidigung:
An der (vermeintlich) wichtigen Stelle hatte ich Quotes :

Code: Alles auswählen

if [ "$PKG" != "$START" ]

Mir wär's ganz lieb, wenn meine dummen Anwenderanfragen nebenbei mitbeantwortet werden könnten

Hatte ich hier [2] gemacht.


[1] http://snapshot.debian.org/package/debt ... ebtree_1.0
[2] viewtopic.php?f=29&t=181683&start=30#p1279512

[JTH]

Mir wär's ganz lieb, wenn meine dummen Anwenderanfragen nebenbei mitbeantwortet werden könnten

Jaja

Nein, die betrachteten Pakete müssen nicht installiert sein, geeqie hab ich z.B. nicht installiert, kann die Skripte trotzdem ausführen. Nur debtree und graphviz brauchen die Skripte zum Ausführen.

Woher der Fehler bei dir kommt, ist mir nicht ganz klar. Ich kann ihn nur provozieren, wenn ich dem Skript nur einen, statt zwei Paketnamen übergebe. Hast du das vllt versehentlich gemacht?

Schoen zu sehen wie viel Potenzial dieses Thema und dieser Thead noch hat!

Mein Wunsch wär, auf dem Wege noch alle Pfade, die zu einer bestimmten Abhängigkeit führen, anzuzeigen. Und super wäre natürlich, zusätzlich die gesuchten Wege zur Vermeidung einer Abhängigkeit rauszufinden.

Edit: Ups, ihr wart schneller.

[Meillo]

Hier eine Version, die abfaengt, ob das Zielpaket eine Abhaengigkeit ist:

Code: Alles auswählen

#!/bin/sh

START="$1"
END="$2"
DKS="${START}.dks"

recurse() {
        if [ "$1" != "$START" ]
        then
                recurse $(sed -n '/[[:space:]"]'$1'[[:space:]"].*\[dist/ {n; s/[]",;]//g; s/.*prev=//p;}' "$DKS")
        fi
        echo "$1"
}

debtree --no-alternatives "$START" 2>/dev/null > "${START}.dot"
dijkstra -dp "$START" "${START}.dot" > "$DKS"
if ! grep -wq "$END" "$DKS"
then 
        echo "$END is no dependency of $START" >&2
        exit 1
fi
recurse "$END"

Zudem sind alle Variablenexpansionen gequotet.

Es fehlt noch auszuwerten, wenn debtree das Startpaket nicht findet. Da muss man schauen was debtree dazu sagt. Vermutlich kann man dessen Return-Wert pruefen. (Aber da ich kein debtree hier habe und es darum nicht testen kann, ueberlasse ich diesen Teil euch.)


@JTH: Bis hier hin war das alles noch nett mit Shell und Co. Wenn es um die von dir gewuenschte, umfassende Umsetzung geht, waere das der Punkt, wo ich (nun, da ich eine Menge ueber das Problem gelernt habe) neu ansetzen wuerde, mit einer passenden Programmiersprache und passenden Datenstrukturen, nicht bloss dieser rudidmentaeren String-Fiddelei. Sondern den Baum im Speicher aufbauen, die Ausgabe auf der internen Datenstruktur basieren, Abstraktion, usw.