Neue Linuxpaketformate

[hikaru]

Wie beurteilt ihr die Diskussion und den Vorteil- Nachteil von übergreifenden Linuxpaketformaten.

https://xkcd.com/927/

[Radfahrer]

Naja, unter Debian sammeln sich auf Dauer halt schon diverse Configleichen in home, wenn man mal ein paar Programme getestet und wieder deinstalliert hat. Purge hin oder her.

Naja, ich möchte nicht, dass der Paketmanager meine Konfigdateien in meinem /home löscht, weil irgendein anderer User ein Programm purged.

Nicht vergessen: Linux ist ein Multiuser-System!
Da wäre es fatal, wenn bei einer Programmdeinstallation gleich alle Konfigs in sämtlichen Homes gelöscht wurden. Aus den Home-Verzeichnissen hat der Paketmanager seine Finger zu lassen.

[uname]

Naja, unter Debian sammeln sich auf Dauer halt schon diverse Configleichen in home, wenn man mal ein paar Programme getestet und wieder deinstalliert hat. Purge hin oder her.

Das Problem ist eigentlich nur, dass im HOME-Verzeichnis sowohl ernsthafte Nutzdaten als auch benutzerindividuelle Konfigurationen abgelegt werden, wofür Purge natürlich nicht zuständig ist. Für openbox und so ziemlich alles lege ich die Konfigurationen unter /etc/xdg ab. Da kann ich gefahrlos von Zeit zu Zeit fast alle Konfigurationen in HOME löschen und somit aufräumen. Ausnahmen sind der Firefox wo ich manuell eine Standard-prefs.js zurückkopiere und evtl. SSH-Konfigurationen in ~/.ssh . Aber dafür hat man ja ein Backup wenn man doch zu viel löscht.

[NAB]

Gibt es irgendwelche Hinweise, dass die neuen Paketformate das Ablegen von Config-Dateien unter /home unterbinden oder diese nachher wieder löschen?

[uname]

Ich weiß von nichts. Aber root hat in meinem Homeverzeichnis rein gar nichts zu suchen auch wenn ich es nicht verhindern kann.

[DeletedUserReAsG]

Doch, kannst du verhindern. Mit SELinux und Ähnlichen. Ob du allerdings # su $user verhindern kannst, ist eine andere Frage – wobei ein Paketmanager, der Configs unter User-~ entsorgen will, hoffentlich nicht su’t …

[ViNic]

make ist in deinem Fall mit A markiert und wird wieder entfernt, um dein Beispiel mal zu zerpflücken. Von aptitude weiß ich es, von apt-get hab ich es gehört. Was synaptic und sonstige Bananensoftware tut, weiß ich nicht.

Ich habe vor dem wiedereinstieg in Debian meist überwiegend apt-get genutzt, zum schluss aptitude. Mit Wiedereinstieg auf Debian 8 nutze ich apt (apt install, apt update, upgrade usw). Kann mich natürlich jetzt irren, aber mit apt remove habe ich kein make gesehen.

[TRex]

make ist in deinem Fall mit A markiert und wird wieder entfernt, um dein Beispiel mal zu zerpflücken. Von aptitude weiß ich es, von apt-get hab ich es gehört. Was synaptic und sonstige Bananensoftware tut, weiß ich nicht.

Ich habe vor dem wiedereinstieg in Debian meist überwiegend apt-get genutzt, zum schluss aptitude. Mit Wiedereinstieg auf Debian 8 nutze ich apt (apt install, apt update, upgrade usw). Kann mich natürlich jetzt irren, aber mit apt remove habe ich kein make gesehen.

Gut, auch damit kann ich dein Beispiel wiederlegen. apt/apt-get brauchen aber beide einen extra-Hieb, was in der Nachricht auch steht beim Deinstallieren.

Installation: 39387
Deinstallation: 39388
"auto-remove": 39389

Und nun hör bitte auf, Gerüchte zu verbreiten.

[ViNic]

Ich habe vor dem wiedereinstieg in Debian meist überwiegend apt-get genutzt, zum schluss aptitude. Mit Wiedereinstieg auf Debian 8 nutze ich apt (apt install, apt update, upgrade usw). Kann mich natürlich jetzt irren, aber mit apt remove habe ich kein make gesehen.

Gut, auch damit kann ich dein Beispiel wiederlegen. apt/apt-get brauchen aber beide einen extra-Hieb, was in der Nachricht auch steht beim Deinstallieren.

Installation: 39387
Deinstallation: 39388
"auto-remove": 39389

Und nun hör bitte auf, Gerüchte zu verbreiten.

In deinem Beispiel installiert es 418 neue Pakete, deinstalliert lazarus + 397 Pakete. Bleiben übrig?

Noch sehe ich mich im Recht

Immerhin ist es beindruckend, das es im Fall von lazarus so gut arbeitet

[Ellison]

https://www.golem.de/news/linux-fedora- ... 29190.html
Fedora macht wohl langsam ernst.

[uname]

Vielleicht habe ich es auch nur falsch verstanden. Aber scheinbar will man eine Art minimal laufendes System als Image bereitstellen und darauf dann mit einer neuen Paketverwaltung das "Desktop-System" zum laufen bringen. Das eigentliche Problem wie z.B. veraltete Bibliotheken im Systemimage wird man damit auch nicht lösen können. Hat Ähnlichkeit mit Windows XP wo man Jahrzehnte das Grundsystem nicht ausgetauscht hat und nur die Anwendungen aktualisiert hat. Gut, dass ich Fedora nicht einsetze und Debian sehr träge ist.

Für mich ist der Desktop auch nur eine dumme Anwendung. Dass der Vorschlag vom Gnome-Team kommt ist verständlich. Gnome ist wohl das neue Betriebssystem Natürlich kann man ein Image anbieten, welches eine feste Auswahl von Debian-Paketen enthält. Geht bestimmt heute schon. Auch kann man Paketlisten und Konfigurationen bereitstellen, die anschließend nachinstalliert werden und einen tollen Gnome-Desktop bereitstellen. Auch das kann man heute realisieren z.B. mit Metapaketen. Am Ende unterscheidet sich es aber nur im Installations- bzw. Updateprozess. Klar ist es viel schneller ein mehrere GB-großes Basis-Image auszutauschen als ein paar veraltete Debian-Pakete Aber deswegen die Paketverwaltung in Frage zu stellen ist dumm, da sie die Sicherheit von Debian ausmacht. Ich denke man muss nur ein paar neue Tools schreiben und ist fertig. Grund für diese Idee ist wohl nur der einheitliche Linux-Desktop der hoffentlich nie kommt.

[syscrh]

Also ich finde den Vorstoß von Fedora persönlich gar nicht gut und letztlich war die Konsequenz der Überlegungen dort nun für mich, dass bei mir keine Red Hat-Systeme mehr laufen (beschränkte sich zuvor auf Fedora-Rechner), da mir die Ideen und Ziele von Red Hat überhaupt nicht zusagen (Systemd, Flatpak, etc.).

Persönlich sehe ich nur wenige Vorteile und vor allem viele Nachteile bei den universellen Linuxanwendungen.
So stellt sich mir z. B. die Frage, wie garantiert werden soll, dass die ausgelieferten universellen Anwendungen auch tatsächlich 1:1 dem Quellcode zu entsprechen (falls diese open source sind). Dieses ernst zunehmende Problem haben wir z. B. heute schon bei Android im Google Play Store. So werden einige vermeintlich quelloffene Anwendungen beim Kompilieren mit weiterem Code "bereichert" und dann als fertige APK ausgeliefert. Das praktiziert z. B. Mozilla so und baut Verbindungen zu den Google Play Services in den Firefox ein, weswegen man bei F-Droid den Firefox forken und in Fennec umbenennen musste. Überprüfen kann man das bei Android auch schlecht, denn die Signatur der Anwendung ist beim selber bauen immer abweichend. Ein Grund, weswegen ich unter Android nur noch F-Droid verwende, denn die setzen wenigstens auf reproduzierbare Builds und ich hab ein gewisses Vertrauen in die Maintainer dort.
Der große Vorteil klassischer Repositories ist für mich, dass ich "nur" meiner Distribution vertrauen muss und diese für mich die Pakete bereits vorsortiert und bereinigt und ich mir dann über die Reinheit und Sicherheit der Pakete keine Gedanken mehr zu machen brauche. Wenn ich die Aussagen und Einstellungen mancher Entwickler im Internet so lese (z. B. Pale Moon, etc.), dann ist es mir schon sehr recht, dass ich die Anwendungen nicht vom Entwickler gebaut bekomme, sondern von einem Dritten, der ggf. noch einmal drübersieht und andere Interessen als der Entwickler verfolgt.

Des Weiteren entfällt womöglich mit den universellen Linux-Paketen der Vorteil einzelner Distributionen. Z. B. ist das bei CentOS und Debian die aufeinander abgestimmte, abgehangene und trotzdem mit Sicherheitsupdates unterstützte Software. Mit universellen Linux-Anwendungen könnte das Problem entstehen, dass, so wie bei Android und Windows, immer nur die neueste Version mit Sicherheitspatches versorgt wird und man damit gezwungen wird ein Rolling Release-Modell mitzumachen und große Änderungen nicht mehr auf einen geplanten Termin verschoben werden können (z. B. neues Debian-Release).

Ehrlich gesagt glaube ich nicht, dass wir dann überhaupt noch verschiedene Distris brauchen und dann haben wir eben ein drittes Monopol (vermutlich Red Hat, denn von denen stammt ja Flatpak) neben macOS und Windows ...

Ein weiterer Kritikpunkt, speziell an Flatpak, ist für mich, dass sich Anwendungen bisher nicht ohne Internetverbindung installieren lassen. Bei Canonical's snaps habe ich das getestet und es geht problemlos (man braucht einmalig die core-snap, konnte man früher aus /tmp/ extrahieren, was man aber zügig mit einem Update unterbunden hatte (-> grandios, wie offen snap zu sein scheint! ), und dann die jeweilige *.snap der Anwendung). Ebenso kann man sich bei Debian einen Offline-Mirror der Repositories mit den benötigten Anwendungen anlegen und diese dann ohne Internet installieren. Bei Flatpak habe ich keine praktikable Lösung finden können und als ich die Frage auf reddit gestellt hatte, kamen mir die Fedora-Nutzer und -Entwickler nur entgegen, dass man sowas doch eh nicht bräuchte im 21. Jahrhundert. Bei Flatpak bin ich also immer darauf angewiesen, dass der Server mit der entsprechenden Runtime verfügbar ist (evtl. ist der ja abgeschaltet in 10 Jahren oder ich bin in einer Gegend auf der Welt, in der es Rechner, aber kein/kaum Internet gibt -> Sowas soll es tatsächlich noch geben, auch wenn das einige nicht glauben können ).

Hier kommen wir zum nächsten Problem: Statt der dezentralen Anwendungsverteilung über verschiedene Distributoren und Repositories, zentralisieren wir nun also die Auslieferung der Anwendungen, denn die jeweiligen Runtimes für snap und flatpak werden dann beim jeweiligen Entwickler der Runtime (Canonical, GNOME, KDE, ...) gehostet und alle Distributoren werden mehr oder weniger gezwungen sein, sich von diesem einen Server abhängig zu machen.


Von den diversen Problemen uralter Libraries, da Entwickler nie auf eine neue Runtime upgraden wollen, und andere Bedenken, gehe ich nicht weiter ein, denn das wurde im Internet schon zu Genüge durchgekaut. Auch halte ich es für Käse zu behaupten, dass die Verfügbarkeit von Linux-Software so schlecht wäre, da es zu viele verschiedene Distributionen gibt (genau genommen gibt es bloß drei große), denn das Problem der Paketierung sollte für einen Entwickler nicht unlösbar sein, sondern höchstens ein wenig Einarbeitung verlangen. Wäre die Verbreitung von Linux höher, dann würden die Entwickler dies sicherlich auch hinbekommen (oder sie veröffentlichen einfach den Quellcode, denn dann machen es die Distris für sie und sie brauchen sich um nichts zu kümmern). Zudem kann man auch in klassischen Linux-Paketen sämtliche Bibliotheken mit in ein Paket einbauen (macht z. B. Arch Linux tlw. so) und das dann verteilen. Man wird dafür nur häufig sein eigenes Repository hosten müssen, da es die Distributionen meist so nicht selber hosten werden. Aber ein eigenes Repository muss man auch bei den neuen universellen Paketformaten verwalten, denn wie sollen die Nutzer sonst Updates erhalten (vorausgesetzt man kann die Anwendung nicht in irgendeinem zentralen "Store" unterbringen)? Aber das kennen die Entwickler dann wenigstens schon so von Windows und macOS und fühlen sich gleich wieder wie daheim ...

Ich bin mir auch bewusst, dass das alles momentan Sorgen von mir sind, die man durchaus lösen könnte und vielleicht auch die Angst vor Neuem mitschwimmt. Aber: Sollte man beim jetzigen Konzept der universellen Linux-Anwendungen bleiben und meine Lieblingsdistribution sich von klassischen Anwendungen und Repositories verabschieden, dann wandere ich zu *BSD ab, denn der Unterschied zwischen macOS, Windows und Linux und damit einer der Vorteile von Linux-Systemen verschwindet für mich dann und es gäbe dann keinen Grund mehr, wieso ich gerade auf die Linux-Basis setzen sollte.

Ich persönlich sehe als einzigen Einsatzzweck für diese neuen Paketformate faule Entwickler (letztendlich gibt es bloß drei große Distris für die man paketieren muss und die meisten anderen können deren Pakete ohne Änderungen übernehmen, wie z. B. Debian -> Ubuntu: Debian, openSUSE, Fedora) und Entwickler proprietärer Software, welche sich nicht mit dem Konzept von shared libraries/code und Repositories anfreunden mögen.

[KBDCALLS]

Ich hab jetzt ganzen Thread nicht durchgelesen, zum Beispiel wird von einem Appimage gehauptet es sei Distributionsabhängig. . Was man von Digikam aber nicht behaupten kann. Das Teil läuft mit Stretch, aber nicht mit Jessie. Soviel zu dem Thema.

viewtopic.php?f=25&t=165864&p=1138027&h ... m#p1138027

Hab übrigens verschiedene ausprobiert. Angeblich soll alles benötige in dem Bundle enthalten sein. Für ein über 300 MB großes Appimage ist das schon nicht wirklich prickelnd

[Nice]

@syscrh, wie so oft bei Deinen Posts: