Flatpak vs RPM? Sind Flatpaks überhaupt sicher?

[Pummeluff]

da kann das system noch so veraltet sein und rumspacken. der flatpak läuft und läuft.

Liegt daran, dass bei Flatpack alle Abhängigkeiten für das zu installierende Paket in die Flatpackumgebung mitinstalliert.

keine ahnung warum so viele flatpaks so verteufeln. viele linux user sind halt oft gewohnheitsmenschen

Hat weniger mit Gewohnheit zu tun.

Wenn du bei Windows eine Software installierst, dann werden sämtliche Abhängigkeiten in der Verzeichnis des Programmes mitinstalliert. Flatpack macht das genauso.

Vorteil: Unabhängig vom OS läuft die Software. Und wenn das über Flatpack installierte Paket 10 Jahre alter oder neuer als das OS ist, die Abhängigkeiten in der Flatpackumgebung werden nicht angerührt.

Nachteil: Durch genau den bei Vorteil genannten Punkt kann es halt vorkommen, dass diverse Libs halt 20x auf Deinem System installiert hast. Und zusätzlich zum OS musst/solltest du auch die Flatpack-Umgebung aktualisieren. Es ist eine Fragmentierung des OS-Managements.

 

[gio127]

Ja, ich denke auch, wenn das was mit Gewohnheit "vieler linux user" zu tun hätte, dann wären diese vielen Linux User immer noch Windows User

 

[netzgestaltung]

also heute hab ich zb qpwgraph installiert um zu schauen ob es sich vom qjackctl-graph unterscheidet.
installiert via RPM gabs eine Fehlermeldung beim Starten. Da das Programm keine Dateizugriffe braucht, flugs Flatpak installiert, läuft. Mein Hauptgegenargument wurde gut formuliert: "Fragmentierung des OS-Managements"

 

[gio127]

installiert via RPM gabs eine Fehlermeldung beim Starten

Auf Fedora? Bei mir läuft es.

 

[netzgestaltung]

Ja Fedora, Meldung:

~$ qpwgraph
qpwgraph: error while loading shared libraries: libQt6Widgets.so.6: cannot open shared object file: No such file or directory

 

[gio127]

Hm, komisch. Ich hatte es gerade, nach deinem Post, installiert (Fedora 37) und läuft, wie gesagt.

Aber für solche Situationen sind flatpaks halt gut

Selbes Problem hatte ich ja mit Dropbox.

Und ja, mir gefällt die höhere Fragmentierung, wie du es nanntes, auch nicht. Auf Windows ist man das ja gewohnt, dass jedes Programm gleich seine eigene Umgebung mitbringt, aber auf Linux war das immer genial gelöst.
Und Flatpaks sind wohl öfters nicht so schön in die Systemoberfläche integriert.

Andererseits versuchen Flatpaks, meines Wissen nach, trotzdem noch teilweise einiges an Umgebung zu teilen, was ich dem Konzept wieder zugute halte.
Und bei immer komplexer werdenden Programmen und Libraries ist diese Umstellung möglicherweise wirklich notwendig. Aber das weiß ich nicht genau, da ich kein Entwickler bin. Und offensichtlich funktionieren ja auch noch alle herkömmlichen Programme, solange sie gepflegt werden.

 

[garfield121]

Die Flatpak Runtimes sind "shared", können also von allen Flatpak-Programmen genutzt werden, die genau diese Version benötigen.

 

[LochinSocke]

Am gesündesten betrachte ich die Reihenfolge:

• Paketmanager der Distribution: Standardrepos, d.h. bei Dir RPM
• Paketmanager der Distribution: offiziell gepflegte Hersteller-Repos, die man zur Repoliste hinzufügt.
• Flatpack, allerdings mit der Prüfung in bestimmten Zeitabständen, ob das Paket nicht bei 1 oder 2 verfügbar ist.
• Wenn es wirklich ganz nötig ist: Einbindung eines sonstigen Repos.
• Wenn es ganz weh tut: Runterladen des Deb, RPM, sonstwas.
• Wenn es noch schlimmer wird: git clone der Sourcen und Bauen des Paketes, vorrangig mit Autobuild für Deb oder RPMBuild für RPMs.

Anstatt Drei würde ich den letzten Punkt ansetzen, Programm bauen und dann ein für den Paket für den Paketmanager schnüren.

 

[garfield121]

Die Deb's tun oft gar nicht weh, einige richten sogar eine zusätzliche Quelle ein (gefragt oder ungefragt), sodas man auch Updates bekommt.