[gelöst] Flatpak, Snap oder lieber selbst kompilieren?
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
[gelöst] Flatpak, Snap oder lieber selbst kompilieren?
Hallo an alle,
nach der Installation einiger Programme ist mir aufgefallen, daß solche die mit Flatpak od. Snap installiert werden ziemlich viel Platz brauchen. Um das zu ändern bin ich nun auf der Suche nach Alternativen, für z.B. Notepadqq. Scheinbar gibt es diese Anwendung nur als Flatpak- oder Snap-Paket, oder habe ich dabei etwas übersehen? Das Programm selbst macht dabei keinerlei Probleme, ich möchte es lediglich "schlanker" installiert haben.
nach der Installation einiger Programme ist mir aufgefallen, daß solche die mit Flatpak od. Snap installiert werden ziemlich viel Platz brauchen. Um das zu ändern bin ich nun auf der Suche nach Alternativen, für z.B. Notepadqq. Scheinbar gibt es diese Anwendung nur als Flatpak- oder Snap-Paket, oder habe ich dabei etwas übersehen? Das Programm selbst macht dabei keinerlei Probleme, ich möchte es lediglich "schlanker" installiert haben.
Zuletzt geändert von MicroCoder am 17.07.2021 10:20:13, insgesamt 1-mal geändert.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Wenn du nicht das Risiko einen ppa eingehen willst, wirst du selber kompilieren müssen.
https://github.com/notepadqq/notepadqq
https://github.com/notepadqq/notepadqq
Re: Flatpak, Snap oder lieber selbst kompilieren?
Ich probiere es mal aus.
Code: Alles auswählen
marc@station2:~$ apt policy notepadqq
notepadqq:
Installed: (none)
Candidate: 2.0.0~beta1-1+b1
Version table:
2.0.0~beta1-1+b1 300
300 http://deb.debian.org/debian unstable/main amd64 Packages
marc@station2:~$ apt install -s notepadqq
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
fonts-mathjax libjs-highlight.js libjs-mathjax libjs-modernizr libjs-requirejs libqt5webengine-data
libqt5webenginecore5 libqt5webenginewidgets5
Suggested packages:
fonts-mathjax-extras libjs-mathjax-doc
The following NEW packages will be installed:
fonts-mathjax libjs-highlight.js libjs-mathjax libjs-modernizr libjs-requirejs libqt5webengine-data
libqt5webenginecore5 libqt5webenginewidgets5 notepadqq
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Inst fonts-mathjax (2.7.9+dfsg-1 Debian:testing, Debian:unstable [all])
Inst libjs-highlight.js (9.18.5+dfsg1-1 Debian:testing, Debian:unstable [all])
Inst libjs-mathjax (2.7.9+dfsg-1 Debian:testing, Debian:unstable [all])
Inst libjs-modernizr (2.6.2+ds1-4 Debian:testing, Debian:unstable [all])
Inst libjs-requirejs (2.3.6+ds-1 Debian:testing, Debian:unstable [all])
Inst libqt5webengine-data (5.15.2+dfsg-3 Debian:testing, Debian:unstable [all])
Inst libqt5webenginecore5 (5.15.2+dfsg-3 Debian:testing, Debian:unstable [amd64])
Inst libqt5webenginewidgets5 (5.15.2+dfsg-3 Debian:testing, Debian:unstable [amd64])
Inst notepadqq (2.0.0~beta1-1+b1 Debian:unstable [amd64])
Conf fonts-mathjax (2.7.9+dfsg-1 Debian:testing, Debian:unstable [all])
Conf libjs-highlight.js (9.18.5+dfsg1-1 Debian:testing, Debian:unstable [all])
Conf libjs-mathjax (2.7.9+dfsg-1 Debian:testing, Debian:unstable [all])
Conf libjs-modernizr (2.6.2+ds1-4 Debian:testing, Debian:unstable [all])
Conf libjs-requirejs (2.3.6+ds-1 Debian:testing, Debian:unstable [all])
Conf libqt5webengine-data (5.15.2+dfsg-3 Debian:testing, Debian:unstable [all])
Conf libqt5webenginecore5 (5.15.2+dfsg-3 Debian:testing, Debian:unstable [amd64])
Conf libqt5webenginewidgets5 (5.15.2+dfsg-3 Debian:testing, Debian:unstable [amd64])
Conf notepadqq (2.0.0~beta1-1+b1 Debian:unstable [amd64])
marc@station2:~$
Code: Alles auswählen
marc@station2:~$ apt policy fonts-mathjax libjs-highlight.js libjs-mathjax libjs-modernizr libjs-requirejs libqt5webengine-data libqt5webenginecore5 libqt5webenginewidgets5
fonts-mathjax:
Installed: (none)
Candidate: 2.7.9+dfsg-1
Version table:
2.7.9+dfsg-1 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libjs-highlight.js:
Installed: (none)
Candidate: 9.18.5+dfsg1-1
Version table:
9.18.5+dfsg1-1 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libjs-mathjax:
Installed: (none)
Candidate: 2.7.9+dfsg-1
Version table:
2.7.9+dfsg-1 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libjs-modernizr:
Installed: (none)
Candidate: 2.6.2+ds1-4
Version table:
2.6.2+ds1-4 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libjs-requirejs:
Installed: (none)
Candidate: 2.3.6+ds-1
Version table:
2.3.6+ds-1 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libqt5webengine-data:
Installed: (none)
Candidate: 5.15.2+dfsg-3
Version table:
5.15.5+dfsg-1 1
1 http://deb.debian.org/debian experimental/main amd64 Packages
5.15.2+dfsg-3 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libqt5webenginecore5:
Installed: (none)
Candidate: 5.15.2+dfsg-3
Version table:
5.15.5+dfsg-1 1
1 http://deb.debian.org/debian experimental/main amd64 Packages
5.15.2+dfsg-3 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
libqt5webenginewidgets5:
Installed: (none)
Candidate: 5.15.2+dfsg-3
Version table:
5.15.5+dfsg-1 1
1 http://deb.debian.org/debian experimental/main amd64 Packages
5.15.2+dfsg-3 990
990 http://deb.debian.org/debian bullseye/main amd64 Packages
990 http://deb.debian.org/debian testing/main amd64 Packages
300 http://deb.debian.org/debian unstable/main amd64 Packages
marc@station2:~$
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Danke für die bisherige Mühe, mein System greift bisher zuerst die Repos von "Buster" ab, den Zugriff auf einen erweiterten Backport hatte ich auch kurz überlegt, dann aber verworfen, da ich nichts finden konnte. Es selbst zu kompilieren ist vielleicht etwas weniger riskant, sollte kein Hexenwerk sein, wenngleich ich das bisher nie machen mußte. Was man dafür braucht ist bei GitHub ganz gut dokumentiert, demnach sollte es auch bei mir klappen. Mal sehen wie es weitergeht.willy4711 hat geschrieben:13.07.2021 18:33:28Wenn du nicht das Risiko einen ppa eingehen willst, wirst du selber kompilieren müssen.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Ich habe mal schlechte Erfahrungen bei einem Bekannten mit dem Snap-Paket für Nextcloud gemacht. Er wollte den Domainnamen umstellen und in der Übergangsphase die Nextcloud über zwei Domainnamen erreichbar machen. Bei einem selbst installierten Nextcloud ist das recht einfach. Für die Snap-Version habe ich bis heute keine Lösung gefunden.
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Inzwischen bin ich um eine weitere Erfahrung reicher!
Nach der restlosen Beseitigung der vorhandenen Flatpaks und den alternativen Installationen außerhalb der üblichen Repos habe ich nun die meisten meiner Anwendungen auf dem neuesten Stand und damit, wie zu erwarten war, ein klein wenig schlanker. Einzige Ausnahme blieb dabei allerdings Notepadqq!
Meine Entscheidung den Quellcode von GitHub herunterzuladen und selbst zu kompilieren führte zwar, da ich scheinbar alles richtig gemacht habe, zu keinem Desaster, aber die Auswirkungen und Konsequenzen, die damit verbunden sind, führten leider zum exakten Gegenteil von dem, was ich eigentlich erreichen wollte.
Zuerst habe ich die vorgegebene Liste an Qt5-Paketen installiert damit das Programm überhaupt kompiliert werden kann. Danach mußte auch noch Git installiert werden, um damit arbeiten zu können, das hatte ich nämlich bisher nie benötigt. Dann wurde gemäß der Anleitung kompiliert und installiert, was nicht nur eine Weile gedauert hat, sondern auch mit heftigen Aktivitäten am Terminal verbunden war, allerdings immer völlig fehlerfrei. Tja, und nach einem Blick in die Anwendungsverwaltung war da eben nicht nur Notepadqq, sonder auch noch die ganze Qt5-Entwicklungsumgebung zu sehen und es funktioniert auch alles problemlos.
Die Ernüchterung allerdings erfolgte unmittelbar darauf, als ich mir die Festplattenbelegung ansah:
Die Flatpak-Installation benötigte deutlich weniger Platz als die nun selbst kompilierte Version! Davor hatte ich knapp 12 GiB für alles benötigt, nun sind es über 12,3 GiB. Nicht etwa, daß das ein echtes Problem wäre, es ist lediglich nicht das was ich wollte. Fazit: Flatpak als Installationslösung ist manchmal doch die kompaktere Variante!
Nach der restlosen Beseitigung der vorhandenen Flatpaks und den alternativen Installationen außerhalb der üblichen Repos habe ich nun die meisten meiner Anwendungen auf dem neuesten Stand und damit, wie zu erwarten war, ein klein wenig schlanker. Einzige Ausnahme blieb dabei allerdings Notepadqq!
Meine Entscheidung den Quellcode von GitHub herunterzuladen und selbst zu kompilieren führte zwar, da ich scheinbar alles richtig gemacht habe, zu keinem Desaster, aber die Auswirkungen und Konsequenzen, die damit verbunden sind, führten leider zum exakten Gegenteil von dem, was ich eigentlich erreichen wollte.
Zuerst habe ich die vorgegebene Liste an Qt5-Paketen installiert damit das Programm überhaupt kompiliert werden kann. Danach mußte auch noch Git installiert werden, um damit arbeiten zu können, das hatte ich nämlich bisher nie benötigt. Dann wurde gemäß der Anleitung kompiliert und installiert, was nicht nur eine Weile gedauert hat, sondern auch mit heftigen Aktivitäten am Terminal verbunden war, allerdings immer völlig fehlerfrei. Tja, und nach einem Blick in die Anwendungsverwaltung war da eben nicht nur Notepadqq, sonder auch noch die ganze Qt5-Entwicklungsumgebung zu sehen und es funktioniert auch alles problemlos.
Die Ernüchterung allerdings erfolgte unmittelbar darauf, als ich mir die Festplattenbelegung ansah:
Die Flatpak-Installation benötigte deutlich weniger Platz als die nun selbst kompilierte Version! Davor hatte ich knapp 12 GiB für alles benötigt, nun sind es über 12,3 GiB. Nicht etwa, daß das ein echtes Problem wäre, es ist lediglich nicht das was ich wollte. Fazit: Flatpak als Installationslösung ist manchmal doch die kompaktere Variante!
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das eigentliche Problem mit Snap ist eben auch, daß es relativ neu ist und daher noch manches nicht so funktioniert wie es sollte. Viele lehnen es daher grundsätzlich ab. Manchmal ist es auch wesentlich komfortabler und sicherer mit einer älteren Version aus den gängigen Repos zu arbeiten, sofern man sie da findet.uname hat geschrieben:14.07.2021 09:42:38Für die Snap-Version habe ich bis heute keine Lösung gefunden.
Re: Flatpak, Snap oder lieber selbst kompilieren?
So neu ist Snap nun auch nicht mehr, und abgelehnt wird’s (zumindest von mir), weil es unkontrollierbar unkontrollierte Software auf das System bringt, die dann natürlich auch gepflegt werden muss. Und zwar alles in dem Paket. Wenn der Maintainer (heißen die da so? Maintainer?) mal keine Lust hat, oder im Urlaub ist, dann bleibt das halt offen. Und wenn ein neues Paket von einem halben GB neu gepackt und geladen werden muss, weil ein sicherheitsrelevanter Patch für eine Lib, die insgesamt vielleicht 10kB groß ist, kam, dann ist die Motivation, das zeitnah zu tun, möglicherweise auch nicht so ausgeprägt – auf beiden Seiten. Auf jeden Fall geht’s nicht so fix von der Hand, wie einfach nur die paar kB der Lib selbst zu updaten.MicroCoder hat geschrieben:15.07.2021 20:46:18Das eigentliche Problem mit Snap ist eben auch, daß es relativ neu ist und daher noch manches nicht so funktioniert wie es sollte. Viele lehnen es daher grundsätzlich ab. Manchmal ist es auch wesentlich komfortabler und sicherer mit einer älteren Version aus den gängigen Repos zu arbeiten, sofern man sie da findet.
Der zusätzliche Plattenplatzverbrauch durch die teils redundanten Sachen ist heute zwar kein großes Problem mehr, ärgerlich ist’s aber allemal. Und wenn dann eine Lib in verschiedenen Versionen (oder gar mehrfach in einer Version) im RAM hängt, statt einmal geladen zu werden und dann zur Verfügung zu stehen, dann ist das auch nicht so richtig toll.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Wenn du nicht vorhast, noch andere Programme zu kompilieren, könntest du die *.dev Pakete, die zum Kompilieren notwendig waren,
entfernen.
entfernen.
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Stimmt, das hatte ich mir gestern auch noch gedacht und heute erledigt. Jetzt liegt die Belegung wieder bei ca. 12 GiB und alles läuft ganz normal. Am Ende habe ich auch nochmal alles überprüft und um sicher zu gehen, daß auch nichts irgendwo liegengeblieben ist, den großen "Besen" eingesetzt (mit sudo apt autoremove).willy4711 hat geschrieben:16.07.2021 08:22:54Wenn du nicht vorhast, noch andere Programme zu kompilieren, könntest du die *.dev Pakete, die zum Kompilieren notwendig waren, entfernen.
Eine Menge Sachen passieren bei alledem im Hintergrund und ohne zusätzlichen operativen Aufwand ist es eben nicht immer einfach die Kontrolle zu behalten.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Tipp:MicroCoder hat geschrieben:16.07.2021 09:34:29Am Ende habe ich auch nochmal alles überprüft und um sicher zu gehen, daß auch nichts irgendwo liegengeblieben ist, den großen "Besen" eingesetzt (mit sudo apt autoremove).
Statt apt autoremove nimm
Code: Alles auswählen
apt autopurge
Kann man auch nachträglich machen mit:
Code: Alles auswählen
aptitude purge ~c
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das genau ist auch der Pferdefuß in der Sache. Zwar ist es manchmal verlockend auf solche Pakete zurückzugreifen weil sie mitunter aktueller sind, aber auch aufgeblähter und unübersichtlicher durch den monströsen Anhang. Leider machen sich nicht alle Entwickler die Mühe unter anderem ein kompaktes Debian-Paket zu schnüren, das auch noch auf dem neuesten Stand ist, damit wäre vieles einfacher.niemand hat geschrieben:15.07.2021 22:52:35Der zusätzliche Plattenplatzverbrauch durch die teils redundanten Sachen ist heute zwar kein großes Problem mehr, ärgerlich ist’s aber allemal. Und wenn dann eine Lib in verschiedenen Versionen (oder gar mehrfach in einer Version) im RAM hängt, statt einmal geladen zu werden und dann zur Verfügung zu stehen, dann ist das auch nicht so richtig toll.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das lässt sich in Bullseye problemlos installierenhikaru hat geschrieben:13.07.2021 18:49:12notepadqq gibt es in Sid und ich würde davon ausgehen, dass dieses Paket unter Bullseye laufen sollte. Falls nicht, sollte es nicht schwer sein einen Backport zu bauen.
Allerdings hat es einen Grave-Bug: 978695
Code: Alles auswählen
apt policy notepadqq
notepadqq:
Installiert: 2.0.0~beta1-1+b1
Installationskandidat: 2.0.0~beta1-1+b1
Versionstabelle:
*** 2.0.0~beta1-1+b1 100
100 /var/lib/dpkg/status
Code: Alles auswählen
# apt install /home/willy/Downloads/notepadqq_2.0.0_beta1-1+b1_amd64.deb
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
[......]
Es müssen noch 757 kB von 1.803 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 9.314 kB Plattenplatz zusätzlich benutzt
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das glaube ich nicht. Es sei denn natürlich, du zählst die Entwicklungsumgebung für die selbstcompilierte Variante mit.MicroCoder hat geschrieben:15.07.2021 20:24:15Die Ernüchterung allerdings erfolgte unmittelbar darauf, als ich mir die Festplattenbelegung ansah:
Die Flatpak-Installation benötigte deutlich weniger Platz als die nun selbst kompilierte Version!
Dann vergleichst du aber Äpfel mit Birnen. Du wirst staunen wie viel Platz du brauchst, wenn du die Entwicklungsumgebung installierst, die du brauchst um das ganze Flatpak von Scratch zu bauen!
... was deutlich einfacher wird, wenn man die Entwicklungsumgebung so kapselt, dass das Wegschmeißen hinterher besonders einfach wird. Für ganz einfach Fälle reicht da pbuilder, in den meisten Fällen ist ein chroot eine gute Lösung und spätestens mit einer voll ausgewachsenen VM kriegt man so ziemlich alles erschlagen.willy4711 hat geschrieben:16.07.2021 08:22:54Wenn du nicht vorhast, noch andere Programme zu kompilieren, könntest du die *.dev Pakete, die zum Kompilieren notwendig waren, entfernen.
Debianpakete zu schnüren ist auch nicht die Aufgabe.der Upstream-Entwickler. Deren Aufgebe ist es, den Quellcode in einfach zu beschaffender Weise bereitzustellen. Nicht mehr und nicht weniger. Alles darüber hinaus (Binaries für N Betriebssysteme, Binary-Distributions-Pakete oder ganze Images mit Binaries) ist nur Kür.MicroCoder hat geschrieben:16.07.2021 10:07:53Leider machen sich nicht alle Entwickler die Mühe unter anderem ein kompaktes Debian-Paket zu schnüren, das auch noch auf dem neuesten Stand ist, damit wäre vieles einfacher.
Aus dem Code Binaries zu machen ist bei FLOSS Aufgabe des Users, oder, wenn er sich die Mühe nicht machen will, Aufgabe der Maintainer seiner Distribution. Und das sollte Upstream dem Distributor auch nicht aus gutem Willen abnehmen (Stichhwort: Fremdquellen), denn der Distributor weiß viel besser wie das Paket zu schnüren ist, um in die Distribution zu passen. Stell dir das Chaos vor das entstehen würde, wenn jedes Paket das du von Debian bekommst, direkt von Upstream käme! Und jedes Upstream-Projekt entscheidet nach Gutdünken selbst über die Abhängigkeiten. Dann kriegst du Zustände die schlimmer sind als unter Windows in den 90ern.
Darum: Währet den Anfängen! Don't break Debian! [1]
Was sprach jetzt nochmal gegen die Installation des momentanen Sid-Pakets unter Bullseye? (Rein technisch gesprochen. Konzeptuell sollte man das generell natürlich nicht machen, denn dann entsteht ein "FrankenDebian" [1] Als leidlich erfahrener Debian-User traue ich mir aber in diesem speziellen Fall zu, den Versuch abzusegnen.)
[1] https://wiki.debian.org/DontBreakDebian
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Danke für den Tipp, habe eben das 2. Kommando umgesetzt und es wurde tatsächlich noch was gefunden, allerdings von anderen Paketen. Allerdings ist das nicht ganz ungefährlich, da war auch noch was von GRUB dabei, zum Glück hat mich das System gefragt ob ich das wirklich löschen will, der Schalter war bereits auf [Nein] gestellt, dabei habe ich es belassen und das war offenbar gut so, das System startet nach wie vor normal.willy4711 hat geschrieben:16.07.2021 09:46:08Tipp:
Statt apt autoremove nimmPutzt auch die Konfigurationsdateien der obsoleten Pakete, die man sonst mit sich herumschleppt.Code: Alles auswählen
apt autopurge
Kann man auch nachträglich machen mit:Code: Alles auswählen
aptitude purge ~c
Re: Flatpak, Snap oder lieber selbst kompilieren?
Hmm an sich ist Aptitude sehr zuverlässig.MicroCoder hat geschrieben:16.07.2021 10:46:10Allerdings ist das nicht ganz ungefährlich, da war auch noch was von GRUB dabei, zum Glück hat mich das System gefragt ob ich das wirklich löschen will, der Schalter war bereits auf [Nein]
Wäre mal interessant, was das für Grub- Sachen waren
Code: Alles auswählen
dpkg -l|grep ^rc
-
- Beiträge: 10
- Registriert: 13.07.2021 17:02:00
Re: Flatpak, Snap oder lieber selbst kompilieren?
Nichts für ungut, aber welche Aufgaben die Upstream-Entwickler für gewöhnlich wahrnehmen und welche nicht, darüber zerbreche ich mir wirklich nicht auch noch den Kopf, das sollte jeder einzelne für sich selbst entscheiden. Tatsache ist, daß es welche tun, nur das ist für mich entscheidend und als solche sind diese für mich vorzuziehen! Ich denke das Betriebssystem ist inzwischen soweit abgesichert, als daß man auch von außerhalb manches installieren kann, ohne Gefahr zulaufen es gleich zu zerstören. Ich jedenfalls will meines konsistent und schlank erhalten und daher entscheide ich über das was von wo und wie installiert wird immer selektiv.hikaru hat geschrieben:16.07.2021 10:43:28Debianpakete zu schnüren ist auch nicht die Aufgabe der Upstream-Entwickler.
Nicht vergessen, Debian ist kein Glaubensbekenntnis, sonder nur eine Distribution von vielen
Re: Flatpak, Snap oder lieber selbst kompilieren?
Da sei dir mal nicht zu sicher. Gerade ein Debian-Paket hat, in dem Moment wo du es installierst, auf deinem System komplette Narrenfreiheit. Das ist, wenn es von einer bewusst bösartigen Quelle kommt, dasselbe, als ob du ungeprüft als root irgendein Shellskript ausführst (in einem Debian-Paket sind es die enthaltenen Maintainerskripte).MicroCoder hat geschrieben:16.07.2021 11:16:52Ich denke das Betriebssystem ist inzwischen soweit abgesichert, als daß man auch von außerhalb manches installieren kann, ohne Gefahr zulaufen es gleich zu zerstören.
Im besten Fall ist es nur kaputt, lässt sich nicht sauber installieren oder schiebt dir für seine eigenen Updates eine neue apt-Paketquelle unter. Im schlimmsten Fall macht es, was es will.
Das soll nicht heißen, dass ich gegen Fremd-Debian-Pakete bin, ich benutze auch welche. Man sollte sich nur bewusst sein, dass auch die ein gewisses Risiko mitbringen, und der Quelle vertrauen.
Manchmal bekannt als Just (another) Terminal Hacker.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Natürlich liegt die Entscheidung bei dir. Aber sie sollte fundiert sein. Daher wäre es durchaus sinnvoll, sich darüber "den Kopf zu zerbrechen".MicroCoder hat geschrieben:16.07.2021 11:16:52Nichts für ungut, aber welche Aufgaben die Upstream-Entwickler für gewöhnlich wahrnehmen und welche nicht, darüber zerbreche ich mir wirklich nicht auch noch den Kopf, das sollte jeder einzelne für sich selbst entscheiden.
Dann erzeugst du zwangsläufig ein "FrankenDebian", mit allen damit verbundenen Nachteilen.MicroCoder hat geschrieben:16.07.2021 11:16:52Tatsache ist, daß es welche tun, nur das ist für mich entscheidend und als solche sind diese für mich vorzuziehen!
Das ist ein Trugschluss. Dahinter steht die Annahme, dass du besser weißt wie Debian funktioniert als die Debianentwickler und -betreuer selbst. Dieses Phänomen ist als "Dunning-Kruger-Effekt" bekannt.MicroCoder hat geschrieben:16.07.2021 11:16:52Ich denke das Betriebssystem ist inzwischen soweit abgesichert, als daß man auch von außerhalb manches installieren kann, ohne Gefahr zulaufen es gleich zu zerstören.
Wenn es bei dir bisher funktioniert hat, beliebige Fremdpakete ohne eingehende Prüfung ihrer Abhängigkeiten zu installieren, dann war es reines Glück, dass bisher noch nichts Unerwartetes passiert ist.
Wenn du dein System konsistent und schlank halten willst, dann ist es kontraproduktiv Fremdquellen zu verwenden. Dieser Thread zeigt das recht deutlich, denn es lässt sich eine eindeutige Konsistenzabstufung erstellen:MicroCoder hat geschrieben:16.07.2021 11:16:52Ich jedenfalls will meines konsistent und schlank erhalten und daher entscheide ich über das was von wo und wie installiert wird immer selektiv.
Die konsistenteste Lösung wäre, auf notepadqq zu verzichten, bis es im von dir benutzten Relesase-Zweig ankommt.
Die zweitkonsistenteste Lösung wäre, einen offiziellen Backport zu verwenden.
Die "zweieinhalbkonsistenteste" Lösung ist, ein Debianpaket aus einem anderen Releasezweig zu verwenden, wenn man nach eingehender Prüfung der Abhängigkeiten befunden hat, dass es einem Backport qualitativ gleichkommt. Genau darauf baut meine Empfehlung zum Sid-Paket auf.
Die drittkonsistenteste Lösung ist, sich selbst ein Debianpaket direkt aus den Upstreamquellen zu bauen.
Die viertkonsistenteste Lösung ist, sich das Programm aus den Upstreamquellen zu bauen ohne ein Debianpaket zu erzeugen. Deiner Beschreibung nach hast du das getan.
Die fünftkonsistenteste Lösung ist, eine binäre Fremdquelle zu benutzen und alle Unstimmigkeiten die sich zwischen der Debianbasis und dem Fremdbinary ergeben, über weitere Fremdbinaries zu lösen, die als Schnittstelle dienen. Das ist der Ansatz von Flatpak.
Je weiter du dich in dieser Abstufung vom Ideal entfernst, desto größer wird auch der Platzbedarf der Lösung, denn du musst mit jeder Stufe mehr zusätzliche Schnittstellen hinzufügen um die Unstimmigkeiten abzufangen.
Debian als Distribution ist v.A. eine hochmodulare Sammlung diverser Pakete mit fein abgestimmten Abhängigkeiten. Es dauert nicht umsonst jedes mal größenordnungsmäßig ein halbes Jahr zwischen Freeze und Release.MicroCoder hat geschrieben:16.07.2021 11:16:52Nicht vergessen, Debian ist kein Glaubensbekenntnis, sonder nur eine Distribution von vielen
Versteh mich nicht falsch, natürlich kannst du auf deinem System tun und lassen was du willst. Deine Beiträge zeigen mir allerdings, dass dir Einiges an Erfahrung im Umgang mit Debian fehlt. Das ist nicht schlimm. Mir geht es hier nur darum klarzustellen, dass dein flapsiger Umgang mit diesem komplexen System nicht als allgemeine Empfehlung taugt.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das ist echt schwierig. Alles nicht ideal'
Mit der Anleitung könnte man das Paket aus sid "selbst backportieren".
https://wiki.debian.org/SimpleBackportCreation
Die build Abhängigkeiten kann man hinterher wieder entfernen. Um die nächste Version zu kompilieren bracht man sie wieder ...
Mit der Anleitung könnte man das Paket aus sid "selbst backportieren".
https://wiki.debian.org/SimpleBackportCreation
Die build Abhängigkeiten kann man hinterher wieder entfernen. Um die nächste Version zu kompilieren bracht man sie wieder ...
Re: Flatpak, Snap oder lieber selbst kompilieren?
Das wäre fast ein Agument für flatpaks ?JTH hat geschrieben:16.07.2021 11:43:11Da sei dir mal nicht zu sicher. Gerade ein Debian-Paket hat, in dem Moment wo du es installierst, auf deinem System komplette Narrenfreiheit. Das ist, wenn es von einer bewusst bösartigen Quelle kommt, dasselbe, als ob du ungeprüft als root irgendein Shellskript ausführst (in einem Debian-Paket sind es die enthaltenen Maintainerskripte).MicroCoder hat geschrieben:16.07.2021 11:16:52Ich denke das Betriebssystem ist inzwischen soweit abgesichert, als daß man auch von außerhalb manches installieren kann, ohne Gefahr zulaufen es gleich zu zerstören.
Im besten Fall ist es nur kaputt, lässt sich nicht sauber installieren oder schiebt dir für seine eigenen Updates eine neue apt-Paketquelle unter. Im schlimmsten Fall macht es, was es will.
Das soll nicht heißen, dass ich gegen Fremd-Debian-Pakete bin, ich benutze auch welche. Man sollte sich nur bewusst sein, dass auch die ein gewisses Risiko mitbringen, und der Quelle vertrauen.
Mist ich habe hier ein(en) Flatpak, Wine für ein Programm und eine externe Quelle
Re: Flatpak, Snap oder lieber selbst kompilieren?
Die Abhängigkeiten sind in Bullseye alle erfüllt, wie ich ja schon gezeigt habe. Da braucht man nichts backportieren oder builden.mcb hat geschrieben:16.07.2021 13:35:52Mit der Anleitung könnte man das Paket aus sid "selbst backportieren".
https://wiki.debian.org/SimpleBackportCreation
Die build Abhängigkeiten kann man hinterher wieder entfernen. Um die nächste Version zu kompilieren bracht man sie wieder ...
Einfach installieren und gut ist.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Schön und gut - der Fragesteller hat aber Buster.willy4711 hat geschrieben:16.07.2021 14:48:55Die Abhängigkeiten sind in Bullseye alle erfüllt, wie ich ja schon gezeigt habe. Da braucht man nichts backportieren oder builden.mcb hat geschrieben:16.07.2021 13:35:52Mit der Anleitung könnte man das Paket aus sid "selbst backportieren".
https://wiki.debian.org/SimpleBackportCreation
Die build Abhängigkeiten kann man hinterher wieder entfernen. Um die nächste Version zu kompilieren bracht man sie wieder ...
Einfach installieren und gut ist.
Re: Flatpak, Snap oder lieber selbst kompilieren?
Nein, so habe ich das nicht gemeint. Auch mit denen kannst du gewisse Risiken eingehen, wie z.B. niemand geschrieben hat. Bei allen, ob deb, Fremd-deb, Snap, Flatpak, AppImage, whatever, solltest du einfach sicher sein, der Quelle vertrauen zu können.
Manchmal bekannt als Just (another) Terminal Hacker.