Abhängigkeitspfade zu systemd und mögliche Alternativen
Re: geeqie und systemd
Ich hatte die Frage so verstanden, dass es eigentlich darum geht, "alle" (die sinnvollen) möglichen Pfade zu finden, um irgendwo sagen zu können, bis hier hin installier mal, den Rest der Abhängigkeiten kannst Du ignorieren.
Re: geeqie und systemd
Stimmt, eggy, das war Quatsch von mir. Die Frage, ob es einen Pfad gibt, ist ja schon durch eine Beobachtung wie "geeqie will systemd mit installieren" positiv beantwortet.
Gesucht wäre eher: Welche(r) Pfad(e) führen zu einer bestimmten Abhängigkeit und - als Bonus - kann man diese durch Alternativen entlang des Pfads vermeiden.
Gesucht wäre eher: Welche(r) Pfad(e) führen zu einer bestimmten Abhängigkeit und - als Bonus - kann man diese durch Alternativen entlang des Pfads vermeiden.
Manchmal bekannt als Just (another) Terminal Hacker.
Re: geeqie und systemd
Ja, das ist richtig. Deshalb schrieb ich ja:eggy hat geschrieben:13.08.2021 07:18:22Ein langer Pfad, von kleinen Paketen, die man bereits auf der Kiste hat, ist vermutlich einem kurzen mit großen Paketen, die dann auch noch installiert werden müssen, vorzuziehen.
Der kürzeste Pfad war nur am einfachsten zu implementieren, weil ich dafür auf die fertige Dijkstra-Implemetierung zurückgreifen konnte.hikaru hat geschrieben:11.08.2021 23:43:29Was ich gern gehabt hätte wäre ein Programm, in das ich zwei Paketnamen stecke, und als Ergebnis erhalte ich entweder den kürzesten, oder alle Pfade zwischen diesen beiden Paketen, aber eben nur zwischen diesen beiden Paketen
Den (topologisch) "kostengünstigsten" Pfad könnte man ermitteln, indem man den jeweiligen Kanten die Größe des Pakets am Ende der Kante als Gewicht zuordnet. Als Bonusaufgabe bekommen bereits installierte Pakete unabhängig von ihrer Größe das Gewicht Null. Das müsste man aber wohl alles selbst implementieren. Freiwillige vor!
Die Frage, ob es einen Pfad gibt ist natürlich die Pflicht. Aber dass es einen Pfad gibt wissen wir bereits von apt. Sonst hätte fischigs geeqie-Installationsversuch nicht systemd angefordert. Nur teilt uns apt diesen Pfad nicht mit.JTH hat geschrieben:13.08.2021 07:23:23Bei der Frage geht's aber doch hauptsächlich um die Frage ob es überhaupt einen Pfad gibt (= kann es sein, dass ein bestimmtes Paket als Abhängigkeit eines anderen installiert werden muss). Die Kosten/Länge des Pfads wäre dabei egal. (Oder vertue ich mich dabei?)
Die früheren Lösungen im Thread ermitteln irgendeinen Pfad. Meine Dijkstra-Variante den Kürzesten. Aber natürlich wäre es interessant alle Pfade (mit Gewichten) zu kennen, um dann den Genehmsten zu wählen. Für eggy wäre das der kostengünstigste in Bezug auf die Installationsgröße. fischig würde gern den seiner Meinung nach "landschaftlich Schönsten" finden. Systemd ist in dieser Betrachtung eine stickige Großstadt, die er gern umfahren würde, auch wenn das "teurer" ist. Das ließe sich algorithmisch erreichen, indem er automatisch ermittelte Gewichte (Paketgrößen) selbst nachjustieren könnte, um so Systemd künstlich sehr hohe Kosten zuzuordnen. Wie du bereits festgestellt hattest gäbe es so eine "landschaftlich schönste Route":
JTH hat geschrieben:12.08.2021 10:09:44Du könntest dbus-user-session und damit systemd also mit Vorab- oder expliziter zusätzlicher Installation von dbus-x11 vermeiden, fischig.
Dann muss ich aber die ganze Kette durch alle Rekursionsstufen mitschleppen.Meillo hat geschrieben:13.08.2021 07:24:55Trotzdem: Wenn du bei einer Rekursion absteigend ausgeben willst, dann machst du die Ausgabe einfach hinter den Rekursionsaufruf.
Mir war die Richtung eigentlich egal. Es war nur ein Hinweis, dass meine Ausgabe andersrum ist.
Re: geeqie und systemd
ähm, ja, ähm *schnell-hinter-dem-nächsten-Baum-versteck*hikaru hat geschrieben:13.08.2021 08:04:20Das müsste man aber wohl alles selbst implementieren. Freiwillige vor!
Re: geeqie und systemd
Wir wollten urspruenglich doch nur wissen *warum* bzw. *worueber* Systemd in die Abhaengigkeit gezogen wird. Diese Frage beantwortet dein Script ... zumindest solange nicht mehrere Abhaengigkeiten wiederum von Systemd abhaengen. In dem Fall sollte man dann eher *alle* Pfade zwischen geeqie und systemd finden wollen.
Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz. Das ist nur darueber aufgekommen, dass man oft alternative Abhaengigkeiten hat und grundsaetzlich wissen wollen koennte, welche Alternativen man jeweils explizit installieren sollte, um am Ende ein moeglichst kleines Abhaengigkeitset installiert zu haben. Das ist aber eine ganz andere Fragestellung.
Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
Waehrend eine aufsteigende Ausgabe so aussieht:
D.h. die Ausgabe vor dem Rekursionsaufruf oder die Ausgabe nachdem er zurueckgekehrt ist.
In deinem Script waere es dann:
(Ich kann's bloss nicht selber testen, weil ich kein geeignetes System zur Verfuegung habe.)
Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz. Das ist nur darueber aufgekommen, dass man oft alternative Abhaengigkeiten hat und grundsaetzlich wissen wollen koennte, welche Alternativen man jeweils explizit installieren sollte, um am Ende ein moeglichst kleines Abhaengigkeitset installiert zu haben. Das ist aber eine ganz andere Fragestellung.
Deine Ausage verstehe ich nicht.
Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
Code: Alles auswählen
function a(n) {
if (n>MAX) return
print n
a(n+1)
}
Code: Alles auswählen
function a(n) {
if (n>MAX) return
a(n+1)
print n
}
In deinem Script waere es dann:
Code: Alles auswählen
...
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
Use ed once in a while!
Re: geeqie und systemd
Hinter dem Abhängigkeitsbaum von geeqie? Den kann man von der Rückseite bestimmt noch besser analysieren!
Manchmal bekannt als Just (another) Terminal Hacker.
Re: geeqie und systemd
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:
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)
...
}
Use ed once in a while!
Re: geeqie und systemd
eggy, JTH und ich in einem Thread ... das kann einfach nicht gut gehen.
Use ed once in a while!
Re: geeqie und systemd
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
... ich erwarte das fertige Script von Euch dann heute abend
Re: geeqie und systemd
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.Meillo hat geschrieben:13.08.2021 08:19:33Wir wollten urspruenglich doch nur wissen *warum* bzw. *worueber* Systemd in die Abhaengigkeit gezogen wird.
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.Meillo hat geschrieben:13.08.2021 08:19:33Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz.
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.
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.Meillo hat geschrieben:13.08.2021 08:19:33Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
[..]
D.h. die Ausgabe vor dem Rekursionsaufruf oder die Ausgabe nachdem er zurueckgekehrt ist.
Alles was du brauchst ist ein debtree-Output:Meillo hat geschrieben:13.08.2021 08:19:33(Ich kann's bloss nicht selber testen, weil ich kein geeignetes System zur Verfuegung habe.)
41437
Ja. Das ganze Script ist im Grunde nur ein Wrapper um die grep-Zeile.Meillo hat geschrieben:13.08.2021 08:30:54In deinem Fall hast du nur genau ein einziges Script, das sich komplett selber aufruft. Das macht es unhandlicher.
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.Meillo hat geschrieben:13.08.2021 08:30:54Wenn 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.
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"!
Wie, heute Abend? Ich war der Ansicht, du präsentierst zur Mittagspause eine ordentliche Lösung.eggy hat geschrieben:13.08.2021 08:42:13... ich erwarte das fertige Script von Euch dann heute abend
Re: geeqie und systemd
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?hikaru hat geschrieben:13.08.2021 09:36:49fischig 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.Meillo hat geschrieben:13.08.2021 08:19:33Wir wollten urspruenglich doch nur wissen *warum* bzw. *worueber* Systemd in die Abhaengigkeit gezogen wird.
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.Meillo hat geschrieben:13.08.2021 08:19:33Das Gewicht der Pfade hat in dieser Fragestellung doch keine Relevanz.
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.
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.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.Meillo hat geschrieben:13.08.2021 08:19:33Generell gesprochen macht man eine absteigende Ausgabe in der Rekursion so:
[..]
D.h. die Ausgabe vor dem Rekursionsaufruf oder die Ausgabe nachdem er zurueckgekehrt ist.
[...]
Ja. Das ganze Script ist im Grunde nur ein Wrapper um die grep-Zeile.Meillo hat geschrieben:13.08.2021 08:30:54In deinem Fall hast du nur genau ein einziges Script, das sich komplett selber aufruft. Das macht es unhandlicher.
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.Meillo hat geschrieben:13.08.2021 08:30:54Wenn 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.
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"!
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
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
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.
Use ed once in a while!
Re: geeqie und systemd
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.Meillo hat geschrieben:13.08.2021 10:03:09Zugegeben, 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.
Am Rande:Meillo hat geschrieben:13.08.2021 10:03:09Dank des von dir geposteten Outputs konnte ich das nun selber testen.
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.
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.Meillo hat geschrieben:13.08.2021 10:03:09Hier eine Umsetzung mit umgekehrter Ausgabe, die deinem Aufbau entspricht:Code: Alles auswählen
# ... if [ $# -lt 3 ] then echo $END fi
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".Meillo hat geschrieben:13.08.2021 10:03:09Und hier eine Version mit Hilffunktion:
[..]
Hier wird der Code IMO deutlich lesbarer.
Ich denke es ist eher eine Frage der Herangehensweise.Meillo hat geschrieben:13.08.2021 10:03:09Man 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.
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.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
Natuerlich ist jede Umsetzung immer ein Zwischenstand auf einem Weg, gepraegt durch seine Vorgeschichte.
Hier nochmal eine Fortentwicklung:
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.
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
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.
Use ed once in a while!
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
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.
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
Use ed once in a while!
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
Da frage ich mich halt aus zweierlei Gründen, ob das sinnvoll ist:Meillo hat geschrieben:13.08.2021 11:32:37Ich gebe doch wieder am Anfang aus und drehe am Ende um, kann dafuer aber alles mit einem einzigen `echo' erledigen.
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:
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.hikaru hat geschrieben:11.08.2021 22:33:40In Bullseye gibt es diesen Abhängigkeitspfad*: geeqie → libgtk-3-0 → libatk-bridge2.0-0 → libdbus-1-3 → libsystemd0.
Nachtrag:
Ja, sehr schön!Meillo hat geschrieben:13.08.2021 11:57:47Und hier als Bonus noch eine Variante, die die Ausgabe am Ende macht und folglich kein Umdrehen braucht:
[..]
Das sollte dir doch nun gefallen, hikaru.
Sieht bei dir aber deutlich freundlicher aus.Meillo hat geschrieben:13.08.2021 11:32:37Die Pipeline um PKG zu finden habe ich zu einem einzigen sed-Aufruf umgebaut -- nur als Alternative, nicht weil es besser waere.
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).
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.Meillo hat geschrieben:13.08.2021 11:32:37Die 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.
In meinem ursprünglichen Ansatz brauchte ich außerdem eine Behandlung für zyklische Abhängigkeiten. Diese erledigt jetzt der dijkstra-Output.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
@Meillo:
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.
https://algorithms.discrete.ma.tum.de/spp/Meillo hat geschrieben:13.08.2021 10:03:09(Dijkstra -- nie gehoert ... also den Algorithmus, denn die Person und seine Denkweisen kenne ich schon ganz gut. )
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.
Wenn ich nur etwas mehr Zeit hätte, würde ich liebend gerne mitspielen, leider passt es grad zeitlich nicht.Meillo hat geschrieben:13.08.2021 10:03:09Wie, heute Abend? Ich war der Ansicht, du präsentierst zur Mittagspause eine ordentliche Lösung.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
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.)hikaru hat geschrieben:13.08.2021 12:12:03Da frage ich mich halt aus zweierlei Gründen, ob das sinnvoll ist:Meillo hat geschrieben:13.08.2021 11:32:37Ich gebe doch wieder am Anfang aus und drehe am Ende um, kann dafuer aber alles mit einem einzigen `echo' erledigen.
1. Ist ein tac vermutlich "teurer" als ein zweites echo.
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.)
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.)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: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.hikaru hat geschrieben:11.08.2021 22:33:40In Bullseye gibt es diesen Abhängigkeitspfad*: geeqie → libgtk-3-0 → libatk-bridge2.0-0 → libdbus-1-3 → libsystemd0.
@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.
Use ed once in a while!
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
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 ausprobiert, indem ich das script mit den Parametern gestartet habe. Außer der Meldung 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“.
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
Code: Alles auswählen
[script] geeqie systemd
Code: Alles auswählen
[script]: 9: test =: unexpected operator
Liegt's daran, dass weder geeqie noch systemd installiert sind?
Eigentlich will ich etwas herausfinden, bevor „das Kind in den Brunnen gefallen ist“.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
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.fischig hat geschrieben:18.08.2021 09:14:14Liegt's daran, dass weder geeqie noch systemd installiert sind?
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
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
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
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
Korrekt. Das ist der Grund fuer die Meldung und die Loesung *dieser* Meldung.hikaru hat geschrieben:18.08.2021 10:21:07Zumindest die "unexpected operator"-Meldungen wird man los, wenn man das $1 in Zeile 9 in Anführunszeichen setzt:Erklären kann ich das momentan nicht. Meillo?Code: Alles auswählen
test "$1" = $START && return
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
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
(*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.)
Use ed once in a while!
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
Das war mir schon klar.Meillo hat geschrieben:18.08.2021 10:46:33Erklaerung: Ohne die Anfuehrungszeichen ersetzt die Shell hier $1 durch einen leeren String
Ich hatte gehofft, dass du hier direkt eine Antwort gehabt hättest.Meillo hat geschrieben:18.08.2021 10:46:33(*Warum* aber $1 ein leerer String ist, das habe ich jetzt nicht nachvollzogen.
Nein,. gab es nicht:Meillo hat geschrieben:18.08.2021 10:46:33Ich wuerde schaetzen, dass es zuvor schon Fehlerausgaben gibt.
Code: Alles auswählen
$ ./meillo.sh abc def &> meillo.txt
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.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
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.
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.
Use ed once in a while!
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
Ja – gibt’s leider nicht mehr. Stattdessen wird auf aptitude why verwiesen.hikaru hat geschrieben:18.08.2021 11:04:53Fü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?
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; }'
Manchmal bekannt als Just (another) Terminal Hacker.
Re: geeqie und systemd (Abhängigkeitspfade und Alternativen finden)
JTH hat geschrieben:18.08.2021 11:38:16Ich 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!)
Use ed once in a while!