Ich war mal so frei: https://forum.archlinux.de/d/35459-bereinigung-alter-repositorys

Da stolpern die Woche über bestimmt noch mehr Leute drüber.

Hallo
Mit der Version 134.0.2 wurde das Problem behoben. Danke für den Hinweis.

Martin-MS Ich zitiere noch mal den Maintainer des Paketes:

Please report any issues.

Probleme mit PKGBUILDs können nur gelöst werden, wenn der Maintainer des PKGBUILDs über Probelme informiert wird. Sich im Forum darüber zu echauffieren, wie der Maintainer es auch nur wagen kann, es nicht so zu machen, dass es bei dir funktioniert, ist jedenfalls der falsche Weg.

Also, ab ins AUR, Fehlerbeschreibung ohne dramatisches Blabla drumherum als Kommentar, und abwarten 🙂

Alternativ halt ganz normal git clone https://aur.archlinux.org/openlinkhub.git und selbst bearbeiten bevor du das Paket baust um es bei dir zu installieren.

Archibaldo Es soll Leute geben, die noch etwas anderes zu tun haben, als staendig zu kontrollieren, ob Arch alles richtig gemacht hat.

Du scheinst trotz (oder wegen?) deiner 13 Jahren Arbeit mit Arch-Derivaten immer noch nicht die von pacman angewandten Mechanismen verstanden zu haben.

Es geht nicht um die Kontrolle, ob Arch alles richtig gemacht hat. Wenn pacman feststellt, dass sich eine Datei des Installationspakets von der auf dem System installierten Datei unterscheidet, was typisch bei Konfigurationsdateien der Fall ist, dann wird diese Datei nicht einfach ersetzt sondern als Kopie abgestellt, und es ist eine Benutzeraktion erforderlich.

Es kommt durchaus vor, dass Entwickler Änderungen am Format ihrer Konfigurationsdateien vornehmen, sei es dass neue Variablen hinzukommen oder sich Bezeichner ändern. Wenn die Konfigurationsdatei nicht mehr zur Anwendung passt, kann es zu mehr oder weniger gravierenden Fehlfunktionen kommen.

Wie sollte sich denn Arch verhalten, so dass es dir genehm ist? Einfach die bestehende Konfiguration mit der aktuellen Fassung unter Verlust der eigenen Modifikationen überschreiben, um die Programmfunktion sicherzustellen? Oder die eigenen Modifikationen respektieren und die Datei nicht ersetzen? Beides würde zu Problemen führen, und deswegen ist ein Benutzereingriff unerlässlich, indem eigene Modifikationen in die vom Entwickler bereitgestellte Konfigurationsdatei übernommen werden müssen. Wer glaubt das nicht machen zu müssen, muss sich später nicht ausheulen, wenn etwas nicht mehr so wie gewohnt oder erwartet läuft.

Das machen andere Distributionen übrigens ähnlich. Bei Debian wird man beispielsweise direkt während der Installation gefragt, wie mit den geänderten Dateien verfahren werden soll. Hier muss man sofort eine Entscheidung treffen, während dieser Prozess bei Arch nachgelagert ist. Entbehrlich ist er aber nie, auch wenn du es noch nie gemacht hast und auch keine Notwendigkeit darin siehst; da arbeitest du eben auf eigenes Risiko.

moonwalker3 Ich arbeite nach dem Prinzip: Keine Optimierung ohne Flaschenhals. Kein Flaschenhals ohne empirische Messdaten.

Gibt es unabhängige Tests, welche auf repräsentativer Hardware einen signifikanten Performanzvorteil von CachyOS gegenüber Arch Linux zeigen?
Falls nein, sind alle Performanzverprechen nur leeres Gerede.

Ja. Meistens findest du nach xyz: command not found, auch das passende Paket mit pacman -F xyz (wenn pacman -F nicht tut erstmal ein pacman -Fy)

tuxnix Bei Arch Linux braucht man das aber nicht wirklich.

Außer natürlich, man möchte bei einer Neuinstallation sehr einfach die Daten erhalten können.

Ich frage mich jetzt ob das, das pacaur ist welches man im AUR findet oder ob man dieses nehmen muss auf welches folgender Link zeigt:
https://github.com/rmarquis/pacaur
Scheint mir nämlich so als wäre das was anderes

Wenn du dir diese Frage nicht selber beantworten kannst, solltest du dich mit makepkg und pacman vertraut machen und erst einmal gar keinen Helper verwenden.

Wenn ich Ubuntu laufen hätte, würde ich auch nicht in ein Debian-Forum gehen und dort um Hilfe bitten. Es kann sein, dass mir dort geholfen werden kann, aber es kann eben auch sein, dass die Leute da gar keine Chance haben, mir zu helfen. Dasselbe gilt für Ableger von Arch.

So wie es aussieht kann dir hier tatsächlich nicht geholfen werden, weil hier (so gut wie) niemand pamac am Laufen hat. Ich persönlich würde in 1000 kalten Wintern nicht auf die Idee kommen, das zu installieren, geschweige denn zu nutzen. Und ich vermute diese Haltung hier in der absoluten Mehrheit.

Letztlich scheinst du einen eigenen Mix aus Distributionen zu nutzen, also Pakete von Arch, aber den Paketmanager von Manjaro. Denke bitte kurz nach und überlege, ob das auf lange Sicht so eine gute Idee ist. Es kann natürlich auch die kommenden Jahre gut gehen, aber erwarte bitte nicht, dass wir das dann nachvollziehen und dir dann ganz konkret helfen können.

josefine
Das ist ein Streitthema, ob es noch Arch ist. Wenn der Installer nur offizielle Paketquellen verwendet und ich mit händischer Installation zum gleichen Ergebnis kommen könnte, würde ich es als Arch bezeichnen.
Was der Calam-Arch-Installer macht, habe ich keine Ahnung. Vielleicht bin ich zu blöd, den Code zu finden, aber auf Sourceforge kann ich keinen sehen. Schon alleine aus dem Grund, würde ich den Installer nicht verwenden.
Und was die Anzeige in neofetch und conky angeht ... das lässt sich beliebig fälschen ändern.