1
Software - Support / Re: kup, bup - wo sind die Einstellmöglichkeiten in Plasma 6
« Last post by Teriarch on Today at 15:05:04 »@paco:
> Gibt es einen nachvollziehbaren Grund, wieso das unter Debian noch hakt?
Ich nehme an, das Debian Entwicklerteam ist noch nicht dazu gekommen. Und natürlich
muss man jeder dankbar sein, die ihre unbezahlte Zeit dafür opfert, die
aktuellen Sourcen in das Paketmanagement zu integrieren und alles konsistent
zu halten ("We are standing on the shoulders of Giants").
Das Kubuntu 0.10.0-0ubuntu1~24.10~ppa1 Release ist ein Backport vom 13.11.2024,
und ich habe es vor der Anpassung auf Abhängigkeitsprobleme mit Debian unstable
überprüft (Das muss man ebenfalls automatisieren, da eine manuelle Überprüfung zu
fehleranfällig ist). Als Referenz habe ich das Shine-On Iso Image genommen. Von einer
abgesehen waren alle Abhängigkeiten erfüllt (Ansonsten ergibt es keinen Sinn weiterzumachen,
da die Konsistenzerhaltung zu aufwändig wird):
kub-backup hängt von libgit2-1.7 ab, aber auf unstable ist libgit2-1.8 installiert (Bei
Kubuntu sind sie wohl auch nicht immer auf dem neuesten Stand, ;-() mit folgender
Konsequenz:
$ ldd /usr/bin/kup-filedigger|grep git:
libgit2.so.1.7 => not found
Und wie erwartet:
$ ls -la /lib/x86_64-linux-gnu/libgit2*:
lrwxrwxrwx 1 root root 16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4
Ich ging davon aus, dass die Versionsänderung der shared Library von 2.1.7 auf 2.1.8
abwärtskompatibel zu den verwendeten APIs ist, deswegen die Einfügung des sybolischen Links:
$ sudo ln -s libgit2.so.1.8 libgit2.so.1.7
mit der Konsequenz
$ ldd /usr/bin/kup-filedigger|grep git
libgit2.so.1.7 => /lib/x86_64-linux-gnu/libgit2.so.1.7 und schließlich
$ ls -la /lib/x86_64-linux-gnu/libgit2*
lrwxrwxrwx 1 root root 14 9. Feb 00:58 /lib/x86_64-linux-gnu/libgit2.so.1.7 -> libgit2.so.1.8
lrwxrwxrwx 1 root root 16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4
Die Erfüllung der Abhaängigkeiten ist zwar notwendig, aber nicht hinreichend für die Funktionalität
(wg. unresolved symbols), aber die geringfügige Versionsänderung ließ mich wie gesagt zuversichtlich
sein.
Ich habe alles an einem kleinen Backup überprüft und kein unerwartetes Verhalten beobachtet. Aus
urheberrechtlichen Gründen sollte jeder das vom Skript modifizierte Paket nur privat installieren und
nicht weitergeben. Wie lange dieses Paket mit dem Paketmanagement von Debian kompatibel bleibt, kann
ich nicht sagen. Schlimmstenfalls wird es bei einem zukünftigen Update wiederr entfernt.
> [...], werde ich es in einer virtuellen Maschine jedoch ausprobieren.
Das empfehle ich auch immer. Und vor allem sollte man niemals ein executable ausführen,
dessen Verhalten man nicht übersieht (es sei denn, man erhält es von vertrauenswürdiger Quelle).
Man kann das Skript auch Zeile für Zeile auf der virt. Machine ausführen, um besser zu verstehen,
was es macht, bevor man es auf einem Produktivsystem laufen lässt.
HTH
> Gibt es einen nachvollziehbaren Grund, wieso das unter Debian noch hakt?
Ich nehme an, das Debian Entwicklerteam ist noch nicht dazu gekommen. Und natürlich
muss man jeder dankbar sein, die ihre unbezahlte Zeit dafür opfert, die
aktuellen Sourcen in das Paketmanagement zu integrieren und alles konsistent
zu halten ("We are standing on the shoulders of Giants").
Das Kubuntu 0.10.0-0ubuntu1~24.10~ppa1 Release ist ein Backport vom 13.11.2024,
und ich habe es vor der Anpassung auf Abhängigkeitsprobleme mit Debian unstable
überprüft (Das muss man ebenfalls automatisieren, da eine manuelle Überprüfung zu
fehleranfällig ist). Als Referenz habe ich das Shine-On Iso Image genommen. Von einer
abgesehen waren alle Abhängigkeiten erfüllt (Ansonsten ergibt es keinen Sinn weiterzumachen,
da die Konsistenzerhaltung zu aufwändig wird):
kub-backup hängt von libgit2-1.7 ab, aber auf unstable ist libgit2-1.8 installiert (Bei
Kubuntu sind sie wohl auch nicht immer auf dem neuesten Stand, ;-() mit folgender
Konsequenz:
$ ldd /usr/bin/kup-filedigger|grep git:
libgit2.so.1.7 => not found
Und wie erwartet:
$ ls -la /lib/x86_64-linux-gnu/libgit2*:
lrwxrwxrwx 1 root root 16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4
Ich ging davon aus, dass die Versionsänderung der shared Library von 2.1.7 auf 2.1.8
abwärtskompatibel zu den verwendeten APIs ist, deswegen die Einfügung des sybolischen Links:
$ sudo ln -s libgit2.so.1.8 libgit2.so.1.7
mit der Konsequenz
$ ldd /usr/bin/kup-filedigger|grep git
libgit2.so.1.7 => /lib/x86_64-linux-gnu/libgit2.so.1.7 und schließlich
$ ls -la /lib/x86_64-linux-gnu/libgit2*
lrwxrwxrwx 1 root root 14 9. Feb 00:58 /lib/x86_64-linux-gnu/libgit2.so.1.7 -> libgit2.so.1.8
lrwxrwxrwx 1 root root 16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4
Die Erfüllung der Abhaängigkeiten ist zwar notwendig, aber nicht hinreichend für die Funktionalität
(wg. unresolved symbols), aber die geringfügige Versionsänderung ließ mich wie gesagt zuversichtlich
sein.
Ich habe alles an einem kleinen Backup überprüft und kein unerwartetes Verhalten beobachtet. Aus
urheberrechtlichen Gründen sollte jeder das vom Skript modifizierte Paket nur privat installieren und
nicht weitergeben. Wie lange dieses Paket mit dem Paketmanagement von Debian kompatibel bleibt, kann
ich nicht sagen. Schlimmstenfalls wird es bei einem zukünftigen Update wiederr entfernt.
> [...], werde ich es in einer virtuellen Maschine jedoch ausprobieren.
Das empfehle ich auch immer. Und vor allem sollte man niemals ein executable ausführen,
dessen Verhalten man nicht übersieht (es sei denn, man erhält es von vertrauenswürdiger Quelle).
Man kann das Skript auch Zeile für Zeile auf der virt. Machine ausführen, um besser zu verstehen,
was es macht, bevor man es auf einem Produktivsystem laufen lässt.
HTH