Seiten: 1 [2]
|
|
|
|
Autor
|
Thema: Fehler beim Erstellen: arcus (Gelesen 2378 mal)
|
|
Sebastian
Sr. Member
Offline
Einträge: 377
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #15 am: 18. September 2022, 17:56:06 »
|
|
@Manfred
Ich pflichte Andreas bei, da nicht mehr weiterzumachen, ich vermute, es fehlt dir noch einiges an Hintergrundwissen. Um zu verstehen, was du da momentan machst.
Es ist zwar schön, dass du Cura alleine wieder zum Laufen gebracht hast. Aber mir scheint, dass du noch nicht genau weißt, warum es mit deinen Befehlen geklappt hat und was snap überhaupt ist. Wenn doch, entschuldige ich mich ganz doll bei dir.
Man sollte auf keinen Fall Befehle ausführen, wenn man nicht weiß, was diese tun. Deswegen immer vorher informieren.
|
|
Gespeichert
|
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 377
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #16 am: 18. September 2022, 18:20:36 »
|
|
@ Andreas
So sieht das ganze bei mir momentan aus
[H533 E0 ~]$ yay -Yc Abhängigkeiten werden geprüft …
Paket (1) Alte Version Netto-Veränderung
libcmis 0.5.2-11 -1,26 MiB
Gesamtgröße der entfernten Pakete: 1,26 MiB
:: Möchten Sie diese Pakete entfernen? [J/n]
|
|
Dies bekommen ich auch noch mal von pacman bestätigt:
[H542 E16 ~]$ pacman -Qdt libcmis 0.5.2-11
|
|
Ich muss aber auch dazu sagen das mein System sehr überschaubar ist und lägst nicht so viele Pakete wie deine Systeme beinhaltet. Durch die Anzahl der installierten Pakete steigt natürlich auch die möglichkeit das da was schiefgehen kann. Erst recht, wenn Abhängigkeiten nicht richtig gesetzt sind oder der Installationsgrund in der pacman Datenbank ein falscher ist.
[H533 E0 ~]$ yay -Ps ==> Yay-Version v11.3.0 =========================================== ==> Insgesamt installierte Pakete: 1035 ==> Installierte Fremd-Pakete: 4 ==> Explizit installierte Pakete: 297 ==> Gesamtgröße der installierten Pakete: 6.4 GiB ==> Größe des pacman-Cache /var/cache/pacman/pkg/: 4.8 GiB ==> Größe des yay-Cache /home/sebastian/.cache/yay: 1.9 GiB =========================================== ==> Die zehn größten Pakete: libreoffice-still: 402.7 MiB brave-bin: 307.6 MiB vscodium-bin: 283.5 MiB linux: 178.5 MiB gcc: 169.9 MiB linux-firmware: 162.6 MiB linux-headers: 144.5 MiB linux-lts-headers: 140.9 MiB gcc-libs: 137.7 MiB linux-lts: 131.0 MiB =========================================== :: Frage AUR ab...
|
|
|
« Letzte Änderung: 18. September 2022, 18:38:13 von Sebastian » |
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1152
Linux von Innen
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #17 am: 19. September 2022, 05:21:35 »
|
|
Wie Du schon schriebst: Dein System ist viel schlanker als meins. So entferne ich auch nicht die Pakete die zum Bauen eines AURs notwendig sind, aber nicht zum Betrieb. Warum? Bei jedem Update müssten die Pakete neu heruntergeladen werden. Bei einem so umfangreichen System wie dem meinen wäre das sehr oft. Dadurch würden die Downloadmengen und -zeiten ziemlich ansteigen:[andreas@wst-andreas ~]$ yay -Ps ==> Yay-Version v11.3.0 =========================================== ==> Insgesamt installierte Pakete: 3962 ==> Installierte Fremd-Pakete: 605 ==> Explizit installierte Pakete: 735 ==> Gesamtgröße der installierten Pakete: 84.5 GiB ==> Größe des pacman-Cache /var/cache/pacman/pkg/: 124.3 KiB ==> Größe des yay-Cache /home/andreas/.cache/yay: 18.4 GiB =========================================== ==> Die zehn größten Pakete: quartus-free-quartus: 8.3 GiB kicad-library-3d: 5.2 GiB quartus-free-modelsim: 4.8 GiB quartus-free-questa: 3.9 GiB cuda: 3.8 GiB unigine-superposition: 2.7 GiB quartus-free-hls: 2.3 GiB pictoblox: 1.7 GiB cuda-tools: 1.6 GiB quartus-free-devinfo-cyclonev: 1.4 GiB =========================================== :: Frage AUR ab... -> Fehlende AUR Pakete: aki celt0.5.1 deepin-grub2-themes deepin-help deepin-manual deepin-qml-widgets deepin-wallpapers-extra downgrader-git electron11 fotoxx-maps gegl02 gnome-documents gnome-shell-extension-status-menu-buttons gtk-theme-adapta gtk-theme-paper gtk-xfce-engine jre10-openjdk jre10-openjdk-headless js js38 js52 js60 js68 kalarmcal kde-l10n-de kdepim-apps-libs kdesudo-frameworks-bzr kfaenza-icon-theme kicad-footprints kicad-symbols lib32-libnm-glib lib32-libva1 liblastfm-qt4 libmediawiki libnm-glib libnm-gtk libopenaptx libva1 libverto-libev monosim-gtk namebench numix-icon-theme numix-icon-theme-square nwt2packet otf-fira-code pcmciautils pdfedit-bin pictoblox plank-theme-numix plasma-mediacenter plasma-scriptengine-superkaramba progsreiserfs pth python-pytest-checkdocs python2-apipkg python2-appdirs python2-babel python2-cairocffi python2-certifi python2-css-parser python2-cssutils python2-dukpy python2-feedparser python2-html2text python2-html5-parser python2-httplib2 python2-iniconfig python2-keybinder2 python2-mechanize python2-ndg-httpsclient python2-ordered-set python2-packaging python2-pam python2-pivy python2-pychm python2-pyparsing python2-pyqt5 python2-pyqtwebengine python2-pyside2 python2-shapely python2-shiboken2 python2-sip-pyqt5 python2-suds python2-svg.path python2-unrardll python2-wxpython python2-wxpython3 python2-xcffib qimageblitz qtcurve-qt4 quartus-free-modelsim saleae-logic-alpha termite-terminfo waldorf-ui-theme welle.io-soapysdr-git xtraceroute yaourt -> Fehlende AUR Debug-Pakete: lxc-git-debug -> Verwaiste AUR-Pakete: aacskeys caja-gksu ddupes electron14 empathy erlang-sdl gimp-plugin-fblur gimp-plugin-lqr gimp-plugin-wavelet-denoise gimp-refocus gnuradio-fcdproplus gtk-recordmydesktop idnkit imagination java-resolver kdelibs kdiff-git libdbusmenu-qt4 libechonest libquicktime log4net obmenu python2-pycryptodomex qt-recordmydesktop saleae-logic systemd-manager tasque xalan-java xerces2-java -> Als nicht aktuell markierte AUR-Pakete: 4kvideodownloader armitage atom direwolf iio-oscilloscope-git kipi-plugins kvpm libkipi nanovna-saver python2-apsw python2-asn1crypto python2-cffi python2-netifaces python2-pycryptodomex python2-pycurl qsstv saleae-logic snapd wireshark-git
|
| Klar: in den Python2-Paketen werde ich irgendwann mal aufräumen (händisch!!!) Python2 ist seit Jahren obsolet, trotzdem setzen immer noch Entwickler darauf, auch für recht neue Pakete Das ist sehr schade - aber Realität.
Ich traue dem Mechanismus der Paketdatenbank in Sachen "kann weg" nicht übe den Weg. Schau Dir mal an was für Pakete da angelich wegkönnen. Das sind wichtige Pakete wie "time", oder auch komplette Desktopumgebungen. Ich weiß 100%-ig dass ich die explizit installiert habe.
LG Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 377
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #18 am: 19. September 2022, 13:45:18 »
|
|
@Andreas
Bist du sicher das wirklich die aufgelisteten Pakete in deiner Pacman Datenbank als --asexplicit also ausdrücklich installiert markiert sind? Diese Pakete dürften nämlich unter keinen Umständen mit von
Gelöscht werden. Sonst handelt es sich hierbei um einen Bug.
Dass der Befehl dir ganze Dekstop Umgebungen löschen möchte, da habe ich eine Vermutung. Desktop Umgebungen werden häufig in Form von Paketgruppen installiert. Die Pakete aus dieser Gruppe werden einzeln unabhänig von den anderen installiert. Vielleicht setzt pacman den Installationsgrund --asdeps bei der Installation über eine Gruppe? Folgerichtig würde nun yay -Yc vorschlagen diese zu deinstallieren, weil sie als Grundangabe nicht mehr gebraucht werden.
Schau doch mal anhand von einem Paket bei dir was als Installationsgrund angeben ist:
pacman -Qi mate-user-guide
|
|
Und ob bei der Abhänigkeitskette nach oben wenigens ein Paket als b]--asexplicit[/b] mit angeben wurde
pacman -Qe $(pactree -ru mate-user-guide)
|
|
Hoffe das ich da jetzt kein Gedankenfehler habe, aber wenn bei der Ausgabe auch nur ein Paket mit dabei ist. Müsste das bedeuten, dass dieses Paket ausdrücklich erwünscht ist und mate-user-guide als tiefere Abhängigkeit nicht deinstalliert werden dürfte. Wenn nichts kommt, denkt yay -Yc, das kann weg, weil die ganze Kette nur als Installationsgrund --asdeps hat.
yay -Yc kann auch nur richtig arbeiten, wenn es auf korrekte Daten zurückgreifen kann. Bzw. Wenn ich das richtig sehe müsse yay -Yc eine Abkürzung von dem hier sein
pacman -Ru $(pacman -Qdtq)
|
|
|
« Letzte Änderung: 19. September 2022, 15:00:59 von Sebastian » |
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1152
Linux von Innen
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #19 am: 20. September 2022, 06:11:29 »
|
|
Mir wird bei pacman -Qi mate-user-guide |
| angezeigt dass es als Abhängigkeit eines anderen Paketes installiert wurde. Bei diesem Paket weiß ich das nicht genau - aber bei einigen anderen weiß ich sehr genau dass ich sie explizit installiert habe. Viele meiner Amateurfunkprogramme wären weg wenn ich das Löschen bestätigen würde. Auch das absolut wichtige Paket "archlinux-keyring" würde gelöscht werden. Die Anzeige dieses Befehls (yay -Yc) ist einfach so absurd dass ich gar nicht weiter darüber nachdenke. Manfred hat ja auch am eigenen Leib erlebt was passiert wenn man das bestätigt. Und viele zu Unrecht entfernte Pakete werden erst später im Laufe der Nutzung des Systems auffallen. Die Ausgabe von pacman -Qe $(pactree -ru mate-user-guide) |
| ist leer. Auch bei brasero - was ich definitiv selbst installiert habe.
Auch viele meiner explizit installierten Sprachunterstützungen hunspell-** würden gelöscht werden. Dieser Mechanismus ist mit einer falschen Erwartungshaltung des Nutzers verknüpft und macht daher gefährliche Vorschläge!! Es ist eben keine KI und kann solche Gedanken wie "schön dass das mitinstalliert wird - das wollte ich sowieso" nicht lesen. Und wenn einem nach Deinstallation des "verursachenden" Programmes auf einmal aufgedrückt werden soll dass die "Abhängigkeit" jetzt überflüssig ist dann fühle ich mich fast so wie bei Microsoft. Nicht ich sondern ein Mechanismus entscheidet für mich was ich brauche und was nicht...
EDIT: Auf meinem zweiten System (nur KDE) werden "go" und "cmake" als Vorschläge für eine Entfernung gemacht. Auch auf diesem System liegt ein Schwerpunkt auf "programmieren" und beide Pakete sind definitiv erwünscht.Ich denke go ist mit installiert worden als ich "paru" installiert habe (aber ich WILL go und es darf auf keinen Fall gelöscht werden!!) und cmake bei einem anderen yay-Programm. Aber auch cmake ist für das Hobby "Programmieren" absolut wichtig. Brasero (auch dort habe ich es definitiv manuell installiert) taucht dort seltsamerweise nicht auf. Vielleicht kann der Status "asexplicit" später noch verändert werden wenn ein anderes Paket installiert wird das von Brasero abhängt, dieses dann aber wieder gelöscht wurde?
LG Andreas
|
« Letzte Änderung: 20. September 2022, 07:52:59 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 377
|
|
Re:Fehler beim Erstellen: arcus
« Antwort #20 am: 20. September 2022, 12:41:42 »
|
|
@Andreas
Es ist eben keine KI und kann solche Gedanken wie "schön, dass das mitinstalliert wird - das wollte ich sowieso" nicht lesen.
|
|
Da hast du recht es kann definitiv keine Gedanken lesen, deswegen muss sich dieser Mechanismus auf den Installationsgrund der in der pacman Datenbank drin steht verlassen. Ist dort angegeben:
Installationsgrund : Ausdrücklich installiert
|
|
So darf das Paket bei der Ausgabe von yay -Yc definitiv nicht mit drin vorkommen, denn ansonsten handelt es sich um einen Bug. Steht hingegen dieser Installationsgrund in Datenbank
Installationsgrund : Installiert als Abhängigkeit eines anderen Pakets
|
|
Dann hangelt sich der yay -Yc Befehl die Abhängigkeitskette nach oben um zu schauen, ob dort wenigstens ein Paket mit dabei ist das Ausdrücklich installiert wurde. Wenn ja dann darf es nicht deinstalliert werden, wenn nein dann sind alle Pakete als Abhängigkeit eines anderen Pakets installiert worden und können somit weg, weil dies kein anderes Paket mehr brauch.
Anmerkung: Die Pakete brauchen sich nicht mehr. Das muss nicht dem Wunsch des Benutzers entsprechen. Falls das der Fall sein sollte, so sollte der Benutzer den richtigen Installationsgrund angeben. Der Mechanismus kann sich nur auf diese Angaben stützen und keine Gedanken lesen.
Dies hast du auch noch mal selbst bestätigt, indem die Ausgabe von pacman -Qe $(pactree -ru mate-user-guide) leer blieb. Dieser Befehl hat sich die ganze Kette nach oben von dem Paket mate-user-guide gehangelt und keins davon hat als Installationsgrund ausdrücklich installiert kann also weg. Der Benutzer hat bei der Installation angegeben, er bräuchte es nur als Abhängigkeit. Oder der Installationsgrund wurde nachträglich irgendwie verändert (vom Benutzer? Ein Skript? etc.)
Da ich es trotzdem komisch finde , weil du dir ja sicher bist das du bestimmte Pakete Ausdrücklich installiert hast, und diese trotzdem zur Deinstallation vorgeschlagen werden, habe ich mal ein wenig weiter recherchiert. Und bin, auch glaube ich, fündig geworden. Am 22. März 2018 wurde folgender Kritischer Bug gemeldet.
Affected Version yay v4.561
Issue Yay marks installed packages as deps always
Steps to reproduce yay -S arduino intellij-idea-community-edition yay -S arduino intellij-idea-community-edition --asexplicit yay -S li nux-zen--asexplicit
|
|
Ich weiß nicht, ob so was vielleicht schon öfter vorgekommen ist, es zeigt aber, dass eventuell geglaubte Ausdrücklich installierte Pakete so nicht in der Datenbank drin stehen. Da man sich auf richtiger weiße auf den default das ohne Angabe von --asexplicit das Paket als Ausdrücklich installiert in der Datenbank hinterlegt wird verlässt.
Da der Befehl yay -Yc also eine korreckt gepflegte pacman Datenbank voraussetzt. Muss man vor dem Deinstallieren von Paketen mit diesen, auf jeden Fall die Ausgabe kontrollieren und verstehen, bevor man mit dem deinstallierten beginnt. Wenn einem da was komisch vorkommt, dann sollte man das lieber, als Grund nehmen seine Paketdatenbank zu prüfen, ob die Installationsgründe richtig bzw. immer noch den Wünschen entsprechen.
Grundsätzlich kann man Installationsgründe auch nachträglich nach einer Installation noch verändern:
Verwendung: pacman {-D --database} <Optionen> <Paket(e)> Optionen: ... --asdeps markiert Pakete als nicht-ausdrücklich installiert. --asexplicit markiert Pakete als ausdrücklich installiert. ...
|
| https://wiki.archlinux.org/title/Pacman#Installation_reason
EDIT:
Habe bei mir das Paket archlinux-keyring mal angeguckt, warum das bei mir nicht deinstalliert werden würde. Das Paket ist ein gutes Beispiel, da die Abhäningkeits-Kette nicht lang ist:
[H499 E1 ~]$ pacman -Qi archlinux-keyring Name : archlinux-keyring Version : 20220831-1 Beschreibung : Arch Linux PGP keyring Architektur : any URL : https://gitlab.archlinux.org/archlinux/archlinux-keyring/ Lizenzen : GPL3 Gruppen : base-devel Stellt bereit : Nichts Hängt ab von : pacman Optionale Abhängigkeiten : Nichts Benötigt von : base Optional für : Nichts In Konflikt mit : Nichts Ersetzt : Nichts Installationsgröße : 1603,09 KiB Packer : Christian Hesse <eworm@archlinux.org> Erstellt am : Mi 31 Aug 2022 09:40:28 CEST Installiert am : Do 01 Sep 2022 21:22:07 CEST Installationsgrund : Installiert als Abhängigkeit eines anderen Pakets Installations-Skript : Ja Verifiziert durch : Signatur
|
|
Ist also eine Abhängigkeit von einem Paket. Bis jetzt würde der Mechanismus noch sagen kann weg.
[H500 E0 ~]$ pactree -r archlinux-keyring archlinux-keyring └─base
|
|
yay -Yc geht also höher und schaut sich base an:
[H501 E0 ~]$ pacman -Qi base Name : base Version : 3-1 Beschreibung : Minimal package set to define a basic Arch Linux installation Architektur : any URL : https://www.archlinux.org Lizenzen : GPL Gruppen : Nichts Stellt bereit : Nichts Hängt ab von : filesystem gcc-libs glibc bash coreutils file findutils gawk grep procps-ng sed tar gettext pciutils psmisc shadow util-linux bzip2 gzip xz licenses pacman archlinux-keyring systemd systemd-sysvcompat iputils iproute2 Optionale Abhängigkeiten : linux: bare metal support [Installiert] Benötigt von : Nichts Optional für : Nichts In Konflikt mit : Nichts Ersetzt : Nichts Installationsgröße : 0,00 B Packer : Jonas Witschel <diabonas@archlinux.org> Erstellt am : Di 19 Jul 2022 16:06:05 CEST Installiert am : Mi 27 Jul 2022 17:20:37 CEST Installationsgrund : Ausdrücklich installiert Installations-Skript : Nein Verifiziert durch : Signatur
|
|
In dem base Paket steht archlinux-keyring als Abhängigkeit und base habe ich ausdrücklich installiert, damit darf mir yay -Yc das Paket archlinux-keyring nicht löschen.
Und da wundert es mich schon ganz stark das base bei dir anscheint nicht als Ausdrücklich installiert in deiner Datenbank drin steht. Bzw. den archlinux-keyring nicht als Abhängigkeit hat.
Da muss schwer was am Argen sein in der pacman Datenbank.
|
« Letzte Änderung: 20. September 2022, 14:38:33 von Sebastian » |
Gespeichert
|
|
|
|
Seiten: 1 [2]
|
|
|
|
|
|
|