Flatpak nutzen, um Gimp 2.10 nutzen zu können?

[Nice]

Endlich ist das langersehnte Gimp 2.10 erschienen: https://www.heise.de/newsticker/meldung ... 28769.html
Leider aber nicht als .Deb-Paket, sondern als Flatpak-Datei.
Eigentlich mag ich Snap und Flatpak nicht und scheue davor zurück, solche Wege zu unterstützen.
Mit Debian-Stable bleibt mir da wohl nur darauf zu warten, bis es in die offiziellen Repositories sickert...

Other opinions?

[eggy]

Habs grade ganz normal per apt-get install gimp in sid installiert.

[Nice]

@eggy: Thx!

Eigentlich habe ich immer wieder daran gedacht, Siduction statt Debian-Stable zu verwenden.
Siduction scheint mir zwar nicht "instabil" zu sein, ein Rolling-Release ist eigentlich wie die Bereitstellung des neuesten Programme (z.B. Firefox und Gimp) auch ganz praktisch, aber mich stören (nerven) dabei die häufigen umfangreichen Updates.

[schwedenmann]

Hallo

Eigentlich habe ich immer wieder daran gedacht, ich Siduction statt Debian-Stable zu verwenden.
Siduction scheint mir zwar nicht "instabil" zu sein, ein Rolling-Release ist eigentlich wie die Bereitstellung des neuesten Programme auch ganz praktisch, aber mich stören (nerven) dabei die häufigen umfangreichen Updates.

Man muß sich halt entscheiden , entweder altbacken stable, oder aktuelle SW per Sid.

mfg
schwedenmann

P.S., immer noch CMYK Support
siehe dazu
https://www.heise.de/forum/heise-online ... 4644/show/

Und gimp 2.10 hat als Eingangsscreen Wilbur nicht mehr

[Nice]

@schwedenmann: Zunächst auch Dir für Deinen raschen Kommentar.

Eigentlich habe ich zwei Entscheidungen zu treffen:
1) Siduction oder Debian-Stable verwenden?
2) Mich auch Flatpak einlassen oder besser nicht?

Unter Debian-Stable kann ich Flatpak installieren und dann die Gimp-Flatpak-Datei nutzen.

Daher: Welche Meinung habt ihr zu "Flatpak"?

Und gimp 2.10 hat als Eingangsscreen Wilbur nicht mehr

Das sagt mir jetzt nichts.
Was bedeutet das?

[schwedenmann]

Hallo



Normalerweise kommt doch dieser Fuchs mit einem Hut (der heißt afaik Wilbur), sobald man gimp strartet erscheint doch ein screnn mit eben Wilbur und unten laufen dann die Mledungen der gestarteten dateien, lugins.

In Gimp 2.10 bei Sid ist dort nicht mehr Wilbur zu sehen , sondern Pilze.

mfg
schwedenbmann

[Nice]

In Gimp 2.10 bei Sid ist dort nicht mehr Wilbur zu sehen , sondern Pilze.

Naja, schwedenmann, das mit dem Wilbur-Logo ist ja kein relevantes Entscheidungskriterium...
Trotzdem Danke für Deine Antwort.

Mein Entscheidungsstand:
Gimp-2.10 oder Firefox-60 sind es mir nicht Wert, auf die Vorzüge von Debian-Stable zugunsten von Siduction zu verzichten.

Es verbleibt die Bewertung von "Flatpak", was ja eine wichtige Grundsatzfrage ist...

[TomL]

Es verbleibt die Bewertung von "Flatpak"

Ich persönlich halte da gar nix von und lehne das als grundsätzliche Alternative natürlich ab. Aber... wie heisst es doch so schön...?... "Keine Regel ohne Ausnahme". Wenn Gimp wirklich neue Funktionen hat, die ich brauche oder unbedingt will, würde ich das ganz pragmatisch entscheiden und es einfach mit der Direktive "vorübergehend bis Buster" als Flatpack installieren. Letztlich gehts um den Zweck, den mein PC für mich hat.... und je besser er den erfüllt, umso besser für mich. Aber wie gesagt, für mich würde die Direktive "vorübergehende Ausnahme-Lösung" gelten. Und wenns irgendwann via Backports verfügbar wäre, fliegt das Flatpak sogar schon früher wieder raus.

j.m.2.c.

[Nice]

@TomL: Danke. Du bestätigst mich in meinen Ansichten.

Meine Gedanken gehen dahin:
1. Über "Snap" brauchen wir erst gar nicht zu reden...
2. "Flatpak" ist - vielleicht - gut gemeint, ich bezweifle aber dass es die Abhängigkeiten der Paketverwaltung gut genug auflösen kann.
3. Eigentlich sollten ".Deb" und ".Rpm" als Lückenbüßer außerhalb der offziellen Paketquellen genügen.
4. Wenn "wir" diese Logik verlassen, verlieren "wir" die Sicherheitsvorteile von Linux und kommen in die ".Exe"-Beliebigkeit von Windows.

[TomL]

Ich war auch mal neugierig... weil ich Gimp auch klasse finde... und habe mal versucht, es selber zu erstellen.... via AppImage von hier:
https://github.com/aferrero2707/gimp-appimage

Teil 1 (als root) läuft durch:

Code: Alles auswählen

apt update
apt full-upgrade
apt install build-essential git jhbuild

mkdir /zzz
mkdir /zyx

chmod 777 /zzz 
chmod 777 /zyx

./bootstrap.sh
chown -R thomas:thomas /zzz

Teil 2 (als 'ich') klappt nicht:

Code: Alles auswählen

./build.sh gimp-appimage
jhbuild build: Ein Modul namens »'gimp-appimage'« konnte nicht gefunden werden.
Usage: jhbuild [ -f Konfiguration ] Befehl [ Optionen ... ]

Da ich hier in meinem Test-systemd-spawnd-Container kein "sudo" installiert habe und die Installation danach irgendwie für Probleme gesorgt hat, musste ich ein paar Mal korrigierend eingreifen. Aber geklappt hats auf die Schnelle trotzdem nicht.

[breakthewall]

Daher: Welche Meinung habt ihr zu "Flatpak"?

Ich kann deine und die Abneigung anderer hier, gegenüber Flatpak nicht wirklich verstehen. Denn allein schon auf technischer Basis, ist das eine ziemlich geile Sache. Ebenso sollte man sich besser darüber informieren, bevor man so negativ urteilt, und von falschen Fakten ausgeht.

Grundsätzlich ist Flatpak keine Bedrohung, noch wird das reguläre Paketmanagement davon tangiert. Sondern es ist vielmehr eine Ergänzung, um die Paketierung von Programmen einfacher und universeller zu gestalten. Nicht zuletzt um die Bürde des regulären Paketmanagements zu nehmen, samt seiner dutzenden Paketformate, was ebenso auch Maintainer entlastet. Damit wird es möglich seine Linux-Distribution in regulärer Form beizubehalten, ohne das man auf Programmversionen im Repository beschränkt ist, was gerade bei Debian-Stable oftmals als problematisch wahrgenommen wird. Und da ein Flatpak von Natur aus überall laufen kann, ist das eine erhebliche Arbeitserleichterung für freie Entwickler, als auch für Entwickler proprietärer Software. Somit wird wiederum der Weg geebnet, um bspw. auch Branchensoftware einfacher zu verteilen.

Ein weiterer Vorteil von Flatpak ist die sichere Ausführung jeweiliger Programme. Sprich, ein Flatpak wird automatisch in einer sehr restriktiven Sandbox ausgeführt, und kann vom Entwickler selbst via Manifest noch stärker eingeschränkt werden. Dieser weiß ohnehin am besten, was sein Programm wirklich an Ressourcen benötigt. Die Sandbox ist weitestgehend vergleichbar mit dem, was bspw. Firejail nutzt um Programme einzuschränken. Also Cgroups, Namespaces, Seccomp-bpf und Linux-Capabilities.

Und GIMP als Flatpak zu nutzen ist denkbar einfach. Zunächst muss Flatpak installiert werden, und dann erfolgt die einmalige Einrichtung eines Repository, wie bspw. Flathub, was die neue Version von GIMP bereits enthält. Im Anschluss wird zunächst die Runtime einmalig heruntergeladen, danach das gewünschte Programm. Eine Runtime enthält grundlegend stabile Abhängigkeiten, um Flatpaks unabhängig systemweiter Abhängigkeiten, universell lauffähig zu machen. So eine Installation kann sowohl via Terminal, als auch grafisch via Doppelklick über eine Webseite erfolgen. Und ähnlich zu regulären Paketen, sind Flatpaks ebenso via SHA512, als auch mittels GPG-Signatur gesichert.

[TomL]

Ich kann deine und die Abneigung anderer hier, gegenüber Flatpak nicht wirklich verstehen. Denn allein schon auf technischer Basis, ist das eine ziemlich geile Sache. Ebenso sollte man sich besser darüber informieren, bevor man so negativ urteilt, und von falschen Fakten ausgeht.

Welche Fakten sind falsch? Diese Fakten, die aussagen, dass sich mit in der Breite etablierten Flatpaks eben auch vermehrt Setup-Pakete ausserhalb des Distri-eigenen Repos quasi als Software aus unbekannten Quellen auf die Rechner schleichen wird? Oder die Fakten, die aussagen, dass sich damit auf der Enduser-Ebene ein eher sorgloserer Umgang mit Fremdquellen einstellen wird, weil Flatpaks neue und aktuelle Programm versprechen und ebenso einfach zu installieren sind, wie Software aus Von-Überall unter Windows? Oder die Fakten, die beschreiben, dass es einfacher ist, ein Flatpak-Setup zu konzipieren, als sich um saubere Abhängigkeiten eines Distri-Repos zu kümmern?

Nun ja, ich bin immer offen für Neuerungen.... weg mit dem alten Kram wie sysvinit-scripte, hurra systemd ... weg mit rsyslog, ntp, sudo, meinetwegen auch weg mit X.... alles kein Problem. Ich habe auch nix gegen Flatpaks, jeder soll sich soviel Müll installieren, wie er mag... genau so wie unter Windows, dubiose Quellen oder nicht, ist mir auch egal... jeder wie er mag. Aber ich hoffe, dass sich Debian da nicht anschließt und den bisherigen Weg des Repos beibehält.

[breakthewall]

Welche Fakten sind falsch?

Nun unter anderem das Flatpak das Paketmanagement negativ beeinflusst, oder die Sicherheit tangieren würde, verglichen mit Windows. Sowas kann man auch nur sagen, wenn man mit der Materie garnicht vertraut ist, und demnach nicht verstanden hat worüber man spricht. Es geht schließlich nicht um ungesicherte Appimages.

Diese Fakten, die aussagen, dass sich mit in der Breite etablierten Flatpaks eben auch vermehrt Setup-Pakete ausserhalb des Distri-eigenen Repos quasi als Software aus unbekannten Quellen auf die Rechner schleichen wird? Oder die Fakten, die aussagen, dass sich damit auf der Enduser-Ebene ein eher sorgloserer Umgang mit Fremdquellen einstellen wird, weil Flatpaks neue und aktuelle Programm versprechen und ebenso einfach zu installieren sind, wie Software aus Von-Überall unter Windows? Oder die Fakten, die beschreiben, dass es einfacher ist, ein Flatpak-Setup zu konzipieren, als sich um saubere Abhängigkeiten eines Distri-Repos zu kümmern?

Das sind doch keine Fakten, nur weil diese Befürchtungen hast. Wie kommt man darauf, dass Flatpaks aus vermehrt unbekannten Quellen kommen werden? Beispielsweise ist Flathub alles andere als unbekannt oder unsicher. Und ich wüsste nicht was Flatpak hier grundsätzlich verändert, was zuvor nicht schon seit Ewigkeiten möglich war. Oder kann man sich nicht Quellcode aus beliebigen Quellen ziehen und kompilieren? Was ist mit fremden Repositories, abseits des Debian eigenen? Verglichen damit wird via Flatpak von Haus aus, nichts mit unbeschränkten Rechten ausgeführt, egal woher es kommt. Ich sehe da absolut keine Gemeinsamkeiten mit Windows. Nebenbei sorgen Ubuntu und Derivate bereits für einen massiv sorglosen Umgang mit Fremdquellen, wofür die PPAs schon Sorge tragen. Und auch wenn Flatpaks theoretisch aus beliebigen Quellen stammen können, so hat man sich sicherheitstechnisch etwas gedacht bei dem Design. Also nicht gleich übertreiben mit dem schwarz malen.

Und die Abhängigkeiten der Linux-Distributionen sind ja wieder eine eigene Angelegenheit, und stehen aktueller Software effektiv im Weg, wenn das System zeitgleich stabil, geprüft und abgehangen sein soll. Jeder kennt das Problem wenn man etwas testen oder nutzen will, was sich massiv mit den Abhängigkeiten des Systems beißt. Und nicht nutzen oder herumfrickeln, ist in nahezu allen Fällen keine Option. Auch Backports kann man oft den Hasen geben, noch werden diese geprüft. Ein Flatpak beseitigt das Problem, doch beeinträchtigt dabei auch nicht die Integrität des Systems. Und wenn man das mal logisch betrachtet, hat es Vorteile gewisse Programme in Flatpaks auszulagern, um die sich ein Distributor schon nicht länger zu kümmern braucht. Somit kann der Fokus vermehrt auf dem Kernsystem liegen, was die Entwicklung vereinfacht und Ressourcen aufteilt.

Aber ich hoffe, dass sich Debian da nicht anschließt und den bisherigen Weg des Repos beibehält.

Wie gesagt, diese Technologien dienen als Ergänzung, und sollen das vorhandene Paketmanagement nicht ersetzen. Auch Debian unterstützt es offiziell, wie auch etliche Desktops. Aber die Nutzung ist dennoch rein optional.

[Nice]

Spaßeshalber habe ich Flatpak und darüber Gimp-2.10 installiert.
Einerseits funktioniert Alles einwandfrei, andererseits wird viel Zeugs installiert.
Zum Beispiel das Software-Center, welches mich nett zum "Einkaufen" einläd.
Und "natürlich" lassen sich Programme, über Flatpak installiert, nicht per Synaptic verwalten.
Ich habe Alles wieder deinstalliert und bleibe erst einmal bei Gimp-2.80.

[breakthewall]

andererseits wird viel Zeugs installiert.
Zum Beispiel das Software-Center, welches mich nett zum "Einkaufen" einläd.

Das ist doch Sache von Apt mögliche Abhängigkeiten auf Wunsch auszulassen.

Code: Alles auswählen

apt --no-install-recommends install flatpak

[Nice]

@breakthewall:

Das ist doch Sache von Apt mögliche Abhängigkeiten auf Wunsch auszulassen.

Nur weiß ich dann erst "hinterher", welche Abhängigkeit doch notwendig war, damit Flatpak ungestört läuft...

[debianoli]

Was ist jetzt eigentlich wieder am Gnome-software-Center so unglaublich böse? Weil da am Start "gehen wir einkaufen" steht? Ja und?

Gimp läuft mit flatpak problemlos. Damit ist ENDLICH der nervige Debian-Bug bei der Käfig Transformation weg.

[Nice]

@debianoli:

Was ist jetzt eigentlich wieder am Gnome-software-Center so unglaublich böse? Weil da am Start "gehen wir einkaufen" steht? Ja und?

Wenn ich ein Programm installiere, gehe ich nicht "Einkaufen", "Jagen", "Spielen" oder sonst was, sonden ich "Installiere" eben.

Ich hoffe immer noch auf ein .Deb-Paket für Gimp-2.10, dann kann ich es in der Synaptic-Paketverwaltung unter Status-Lokal übersichtlich verwalten.

[KBDCALLS]

gimp 2.10 gibt es doch in Sid . Wo ist das Problem ?

Das Flatpak keine Gariantie ist das etwas läuft, habe ich an Jessie und Digikam gesehen. Hab aber auch nicht weiter nachgeforscht.

[Nice]

Eine Alternative wäre ein Appimage von Gimg-2.10, als portable Anwendung:
https://appimage.org/
https://appimage.github.io/apps//
Genauer: https://github.com/aferrero2707/gimp-appimage/releases

Aber auch hier ist die Frage, ob es sich gut in das Gesamtsystem einfügt und wie man die Updates pflegen will...

[KBDCALLS]

Die eigentliche Frage haste immer noch nicht beantwortet. Warum kann man die Version aus SID nicht nehmen?

[Nice]

@KBDCALLS:

Die eigentliche Frage haste immer noch nicht beantwortet. Warum kann man die Version aus SID nicht nehmen?

Ich habe es einfach überlesen...
Also Gimp-2.10 in Debian-Stable durch die Stretch-Backports nutzen - da steht es noch nicht zur Verfügung.
Und wie soll ich unter Debian-Stable an Sid-Pakete kommen?
Die einzige Möglichkeit, die ich sehe wäre, Siduction zu installieren, was ich aber wegen den häufigen Updates dort nicht will.

[KBDCALLS]

Also Gimp-2.10 in Debian-Stable durch die Stretch-Backports nutzen?

Das könnte schwierig werden. Den Backport müßte man selbst kompilieren. Und babl und gegl auch . Wenn nicht noch mehr .

[Nice]

@KBDCALLS:

Warum kann man die Version aus SID nicht nehmen?

Ja, O.K. und jetzt frage ich Dich, wie ich unter Debian-Stable an das Gimp-2.10-Paket aus Sid herankommen soll?
>>> Antwort gefunden: https://packages.debian.org/sid/amd64/gimp/download
Das wäre ja dann das von mir gewünschte .Deb-Paket (gimp_2.10.0-3_amd64.deb).
Aaaber: beim Installationsversuch kommt natürlich eine Fehlermeldung, bezüglich nicht erfüllbarer Abhängigkeit.

Damit ist die Frage "Warum kann man die Version aus SID nicht nehmen?" beantwortet: Weil es mit dem Debian-Stable-System nicht zusammengeht.

[KBDCALLS]

So ohne weiteres dürfte das nicht funktionieren.

• Code: Alles auswählen

  The following packages have unmet dependencies:
   pbuilder-satisfydepends-dummy : Depends: gegl (>= 0.4.0) but it is not going to be installed
                                   Depends: libbabl-dev (>= 0.1.46) but it is not going to be installed
                                   Depends: libfontconfig1-dev (>= 2.12.4) but 2.11.0-6.7+b1 is to be installed
                                   Depends: libgegl-dev (>= 0.4.0) but it is not going to be installed
                                   Depends: libgexiv2-dev (>= 0.10.6) but it is not going to be installed
                                   Depends: libglib2.0-dev (>= 2.54.2) but 2.50.3-2 is to be installed
                                   Depends: libmypaint-dev (>= 1.3.0) which is a virtual package and is not provided by any available package
  
                                   Depends: libwebp-dev (>= 0.6.0) but it is not going to be installed
                                   Depends: mypaint-brushes which is a virtual package and is not provided by any available package
  

Das ist aus dem .configure

• Code: Alles auswählen

  # These are used in the .pc files
  GLIB_REQUIRED_VERSION=2.54.2
  GDK_PIXBUF_REQUIRED_VERSION=2.30.8
  GTK_REQUIRED_VERSION=2.24.10
  GTK_WIN32_RECOMMENDED_VERSION=2.24.32
  CAIRO_REQUIRED_VERSION=1.12.2
  CAIRO_PDF_REQUIRED_VERSION=1.12.2
  GEGL_REQUIRED_VERSION=0.4.0
  GEXIV2_REQUIRED_VERSION=0.10.6
  LCMS_REQUIRED_VERSION=2.8
  LIBPNG_REQUIRED_VERSION=1.6.25
  LIBLZMA_REQUIRED_VERSION=5.0.0
  LIBMYPAINT_REQUIRED_VERSION=1.3.0
  PANGOCAIRO_REQUIRED_VERSION=1.29.4
  BABL_REQUIRED_VERSION=0.1.46
  FONTCONFIG_REQUIRED_VERSION=2.12.4
  FREETYPE2_REQUIRED_VERSION=2.1.7
  HARFBUZZ_REQUIRED_VERSION=0.9.19
  WEBKIT_REQUIRED_VERSION=1.6.1
  ATK_REQUIRED_VERSION=2.2.0
  RSVG_REQUIRED_VERSION=2.40.6
  WMF_REQUIRED_VERSION=0.2.8
  POPPLER_REQUIRED_VERSION=0.44.0
  POPPLER_DATA_REQUIRED_VERSION=0.4.7
  OPENEXR_REQUIRED_VERSION=1.6.1
  INTLTOOL_REQUIRED_VERSION=0.40.1
  PERL_REQUIRED_VERSION=5.10.0
  PYTHON2_REQUIRED_VERSION=2.5.0
  WEBP_REQUIRED_VERSION=0.6.0
  XGETTEXT_RECOMMENDED_VERSION=0.19