News Linux User Repository: LURE soll ein AUR für alle Distributionen sein

Tanzmusikus schrieb:
Verstehe deine Ansicht in dem Falle nicht.
Meine Ansicht beruht darauf, dass beide Varianten Vor- und Nachteil haben.
AUR ist platzsparender, da nativ und es werden die system-eigenen deps verwendet. Flatpaks muss man nicht kompilieren und sind je nach Paketverwalter auch sicherer, brauchen dafür mehr Platz, weil die deps separat sichergestellt werden müssen.
Oder liegt das Missverständnis woanders? Vielleicht war ich nicht deutlich genug. Auf dem Steam Deck nutze ich Flatpaks, weil es reicht und ich mich nicht darum kümmern muss, dass nach einem Update wieder etwas installiert werden muss.
Hingegen nutze ich auf meinem Laptop Arch und da kann ich auf das AUR zugreifen, was ich insbesondere aus Platzgründen (auch wenn ich genügend Speicher habe) primär verwende.
 
Mihawk90 schrieb:
Ich nutze selbst nicht Arch, aber von dem was ich so mitbekommen habe geht das mit den Abhängigkeiten eigentlich, wenn man sich dessen bewusst ist und bei einem auftretenden Problem einfach direkt eine neue Kompilierung anstößt.
Du meinst vermutlich so etwas wie "Update Package" (pacman -Syu bzw. yay oder gar pacman -Syyu bzw. yay -Syyu?
https://wiki.archlinux.de/title/Pacman#Synchronisation_und_Installation_von_Paketen
https://linuxcommandlibrary.com/man/yay#examples

Deinorius schrieb:
Oder liegt das Missverständnis woanders?
Ich nahm an, dass Du Flatpak aus irgend einem Grund besser geeignet findest, sodass es statt AUR genutzt werden sollte, siehe:
Deinorius schrieb:
Finde beides gut, aber man sollte sich für eines entscheiden und nur ausnahmsweise zusätzlich das jeweils andere verwenden.
Warum sollte man sich für eine der beiden Paketinstallationsformen entscheiden?
Es funktionieren auch beide problemlos nebeneinander her. Zumindest bei mir am PC oder Noteboook.

Gibt's da etwa ein Problem mit dem Steamdeck in diesem Zusammenhang?
Ich dachte, das Steamdeck ist quasi ein vollständiges Linux-Betriebssystem - nur eben (meist/immer?) im "Big Picture Modus" o.s.(?).
 
Tanzmusikus schrieb:
Du meinst vermutlich so etwas wie "Update Package"
Nein ich meine die Neukompilierung auf Seiten des Repositories, damit du im Package Manager überhaupt erst ein Update angezeigt bekommst.

Tanzmusikus schrieb:
Gibt's da etwa ein Problem mit dem Steamdeck in diesem Zusammenhang?
Kein "Problem" aber das Steamdeck nutzt ein read-only (bzw immutable) root. Das muss zunächst deaktiviert werden (nicht schwer, Valve gibt ne Anleitung) um native Pakete installieren zu können. Dabei gilt aber zu beachten, dass das Paket beim nächsten SteamOS Update entfernt wird. Das ist bei Flatpaks eben nicht so.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Deinorius und Tanzmusikus
Deinorius schrieb:
Flatpaks muss man nicht kompilieren und sind je nach Paketverwalter auch sicherer, brauchen dafür mehr Platz, weil die deps separat sichergestellt werden müssen.
Wobei bei den Flatpaks, soweit ich verstanden habe, als einziges von diesen neuen Formaten (snaps appimages) auch Abhängigkeiten unter den verschiedenen Flatpaks geteilt werden. Somit ist es etwas platzsparender als snap oder appimage.
Das finde ich lobenswert. Darum nutze ich auch nur flatpaks, wenn es sonst keine andere Alternative gibt. Z.B. habe ich mal das Programm Natron ausprobiert, was beim kompilieren probleme gemacht hatte. Dann hab ich es einfach als flatpak installiert.
 
  • Gefällt mir
Reaktionen: Deinorius
gio127 schrieb:
Abhängigkeiten unter den verschiedenen Flatpaks geteilt werden. Somit ist es etwas platzsparender als snap oder appimage.

Platzsparender als AppImage ja, aber auch Snap teil Abhängigkeiten.

1666371942146.png


Z.b. diese Gnome und KDE Pakete sind im Grunde das gleiche wie die "Gnome Application Platform" Pakete in Flatpak.
 
  • Gefällt mir
Reaktionen: gio127 und Tanzmusikus
Eine andere Möglichkeit , Pakete für mehr als eine Distribution zu bauen und zur Verfügung zu stellen wäre OpenSuses OBS. Es wäre schön wenn sich beide Projekte ergänzen und befruchten könnten.
Ergänzung ()

Bei allen Paketformaten die ihre Abhängigkeiten (teilweise) selbst mitbringen hat man das Problem das wenn in einer der selbst mitgebrachten Abhängigkeiten ein Sicherheitsloch entdeckt wird, dieses nicht mehr allein durch Updaten der darunterliegenden Distribution beseitigt werden kann. Sondern es müssen auch ein oder mehrere Pakete deswegen upgedated werden . Und es kann schwierig werden zu überprüfen ob alle benutzten Pakete dieses Loch gefixt haben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: gio127 und Tanzmusikus
mkossmann schrieb:
Es wäre schön wenn sich beide Projekte ergänzen und befruchten könnten.
Es wird vermutlich so sein, dass LURE auf dieses OpenSuse-OBS zugreifen kann.
LURE nutzt ja wie Topgrade & Yay die Package-Manager der jeweiligen Distribution.
 
Tanzmusikus schrieb:
Warum sollte man sich für eine der beiden Paketinstallationsformen entscheiden?
Es funktionieren auch beide problemlos nebeneinander her. Zumindest bei mir am PC oder Noteboook.
Natürlich funktionieren die problemlos nebeneinander, aber Flatpaks gibt es aus dem Grund, damit man Distro-unabhängig Programme installieren kann, während Arch gerade wegen dem AUR populär ist und man im Normalfall auf Flatpaks verzichten könnte, sofern einem das Kompilieren nicht stört (alternativ gibt es das chaotic AUR).
Flatpaks und das AUR sind jeweils die Lösung für das selbe Problem mit Vor- und Nachteilen. Wenn man jetzt zwischen beiden Lösungen wechselt, hat man eher Nachteile als Vorteile IMO. Es ist je nach Programmanzahl nichts schwerwiegendes, aber ich finde es wischi-waschi, wenn man das nicht strikt getrennt nutzt.

Ich sage, es gibt zwei sinnvolle Nutzungsvarianten:
Für die einfache Variante nutzt man ausschließlich Flatpaks, während man aus dem AUR jene Pakete installiert, die es nicht auf Flathub gibt.
Wen kompilieren nicht stört, oder sich über alles bewusst ist, wird so ziemlich alles auf AUR finden bzw. ansonsten den Github Source Code direkt kompilieren, wie ich es am Laptop (nicht auf dem Steam Deck) mache.

gio127 schrieb:
Wobei bei den Flatpaks, soweit ich verstanden habe, als einziges von diesen neuen Formaten (snaps appimages) auch Abhängigkeiten unter den verschiedenen Flatpaks geteilt werden. Somit ist es etwas platzsparender als snap oder appimage.
Nun ja, AppImages sollte man auch nur dann verwenden, wenn es anders nicht geht. Also kein AUR, keine Flatpak Variante und snaps einfach gar nicht nutzen.
Es ist gerade für Nightly-builds nützlich, damit man diese einfach austesten kann, oder immer die aktuellste Version von einem Programm hat, das nicht zwingend installiert sein muss. Ich mag auch AppImages, verwende diese aber dennoch kaum.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und gio127
Tanzmusikus schrieb:
Du meinst vermutlich so etwas wie "Update Package" (pacman -Syu bzw. yay oder gar pacman -Syyu bzw. yay -Syyu?
-Syyu ist in aller aller aller Regel unnötig.
Und nein, das reicht nicht, wenn AUR-Pakete neu kompiliert werden müssen - dafür müsste man z.b. yay Paketname ausführen.

Deinorius schrieb:
AUR ist platzsparender, da nativ und es werden die system-eigenen deps verwendet. Flatpaks muss man nicht kompilieren und sind je nach Paketverwalter auch sicherer, brauchen dafür mehr Platz, weil die deps separat sichergestellt werden müssen.

Ein großer Vorteil von Flatpaks ist in meinen Augen die Sandbox. Man muss natürlich schauen, dass das Paket nicht einfach Zugriff auf alles anfordert, sondern vernünftig konfiguriert ist und es ist natürlich keine vollständige Isolierung - aber es ist auf jeden Fall besser als nichts und grade für Programme, die Online sind (Messenger, Browser) oder geschlossenen Code ausführen (z.b. Bottles) eine einfache Verbesserung der Sicherheit, ohne dass der User sich mit einer MAC rumschlagen müsste.
 
  • Gefällt mir
Reaktionen: Deinorius und Tanzmusikus
Zurück
Oben