zur Startseite

Druckausgabe von https://www.bilddateien.de/
bilddateien.de

Zweite Instanz von darktable für Linux - die einfache Variante

veröffentlicht am 10.01.2024 in * PROGRAMME * SOFTWARE *

Inhaltsverzeichnis

 

Nach wie vor bin ich nicht in der Lage, auf meinem aktuellen Debian-System die aktuellen Master-Versionen zu bauen, um ein Gefühl dafür zu bekommen, was da zu erwarten ist (und den jeweiligen Artikel vor der offiziellen Veröffentlichung sinnvoll vorbereiten zu können). Aber kurz vor Veröffentlichung der Version 4.6 wurde ich auf eine Ausweichmöglichkeit hingewiesen …

Zwei Versionen von darktable nebeneinander betreiben

Anmerkung: es geht hier um den Betrieb von darktable unter Linux, genauer: Debian 12 (Bookworm)

Die Voraussetzungen

Für den produktiven Einsatz nutze ich stets die für meine Distribution erstellten Pakete über den Paketmanager. Nun soll also zusätzlich eine zweite Version von darktable für Tests oder Vergleichszwecke hinzuinstalliert werden (ohne die vorhandene Installation zu überschreiben!).

Um die hier genannten Voraussetzungen zum Betrieb zweier oder mehrerer verschiedener Versionen von darktable zu verstehen, ist die Kenntnis des Artikels zum Backup der darktable-Einstellungen hilfreich.
Wie dort erläutert, speichert darktable seine Anwendungsdaten

Die ausführbaren Programmdateien liegen bei Linux-Systemen in der Regel in Unterverzeichnisssen von /usr, also in der Regel /usr/bin, /usr/lib und /usr/share.

An keinem dieser Orte darf durch die Zweitinstallation “Schaden angerichtet werden”, es dürfen dort also keine Dateien überschrieben oder unbeabsichtigt modifiziert werden.

Lösungsansatz

Installation der ausführbaren Dateien

Hier kommen zwei Möglichkeiten in Betracht:

  1. Installationspaket für das Betriebssystem aus dem Entwickler-Repositiory herunterladen und mittels
    dpkg -i --root=/opt/darktable-master darktable_{Versionsbezeichnung}_amd64.deb
    an einen anderen Ort installieren (Achtung: ungetestet)
  2. Quellcode herunterladen und selbst kompilieren, dabei läßt sich der Installationspfad festlegen - dieses Vorgehen hatte ich in meinem vorherigen Artikel beschrieben
  3. Seit einiger Zeit stellen die Entwickler selbst sog. nightly builds zur Verfügung - das sind fortlaufend akutalisierte ausführbare Programmdateien. Für Linux liegen diese im AppImage-Format vor. Und darauf basierend werde ich hier meine Vorgehensweise beschreiben.

Anwendungsdaten

  1. Wenn man darktable aus dem Terminal startet, dann hat man die Möglichkeit, die Optionen --configdir und --cachedir zu benutzen, damit werden die Anwendungsdaten nicht in die Standard-Profilverzeichnisse gespeichert, sondern deren Orte können vorgegeben werden.
  2. .xmp-Sidecar-Dateien
    • In den darktable-Voreinstellungen läßt sich das Schreiben dieser Dateien verhindern, dann werden die Bearbeitungsschritte ausschließlich in der darktable-Datenbank gespeichert. Das mag für eine Testumgebung ausreichend sein, für das Produktivsystem würde ich nie auf das “Auffangnetz” der xmp-Dateien verzichten wollen.
    • alternativ kann man auch ein paar Testdateien in ein eigenes Verzeichnis kopieren und nur dieses in der Testinstallation importieren und damit arbeiten.

Nachdem jetzt also geklärt ist, worauf zu achten ist und wie die Probleme gelöst werden können, kann’s losgehen:

AppImage als Lösung?

Das darktable-Projekt stellt sog. Nightly Builds aus dem Entwicklungszweig zur Verfügung - diese werden als “gebrauchsfertige” Binaries für Windows (.exe), MacOS (.dmg) sowie für Linux als AppImage zur Verfügung gestellt.

Hier soll es um die Nutzung - insbesondere für Linux - einer darktable-“Installation” als zweite Instanz “zum Ausprobieren und Spielen” gehen.

AppImage? Eine kurze Einführung …

Dieser Abschnitt kann übersprungen werden bei entsprechenden Vorkenntnissen
Linux - ebenso wie jedes andere halbwegs effiziente Betriebssystem - nutzt sog. geteilte Resourcen für das Ausführen von Programmen und Anwendungen. Das heißt, daß bestimmte Funktionalitäten, die anwendungsübergreifend benötigt werden, in sog. “Bibliotheken” (engl. Libraries) ausgelagert werden (das können z. B. Elemente sein, die zum Aufbau der Benutzeroberfläche benötigt werden: Buttons, Anzeigefenster, Diagrammerstellungen etc.). Jeder Linux-User kennt in diesem Zusammenhang den Begriff “Abhängigkeiten”.

Was zunächst eine sinnvolle Vorgehensweise ist, das wird dann zum Problem, wenn man eine neuere Programmversion auf einem älteren Betriebssystem laufen lassen will (manchmal auch im umgekehrten Fall), weil dann evtl. auf Bibliotheken einer anderen Version zurückgegriffen wird, die nicht zu den vom Programm gestellten Anforderungen passen.
Und hier kommen jetzt die sog. AppImages (zur Historie siehe Wikipedia) ins Spiel:

AppImage Logo

Diese bringen als Gesamt-Paketlösung alles in der richtigen Version mit, was das jeweilige Programm zum Laufen benötigt. Das macht die jeweiligen Programme zwar “autark” bzgl. des Betriebssystems, die Bedarfe an Speicherplatz sowohl auf der Festplatte als auch im Arbeitsspeicher (RAM) steigen aber deutlich.

darktable als AppImage

Die normalen stabilen Versionen von darktable werden nach wie vor über die jeweiligen Paketmanager der jeweiligen Linux-Distribution zur Verfügung gestellt; wenn dort die aktuellen Versionen nicht verfügbar sind, dann sei das OBS-Repository als Anlaufstelle empfohlen.

Um aber schnell und einfach Entwicklungsstände zur Verfügung stellen zu können, ohne diese erst für eine Vielzahl von Betriebssystemen und insbesondere Linux-Distributionen erstellen zu müssen, gibt es die Entwicklungsstände zentral von der github-Seite des darktable-Projekts zum Download.

Diese haben dann solche schönen und “einfachen” Dateinamen wie Darktable-4.7.0+98.gbce83d51a9-x86_64.AppImage - dahinter verbirgt sich dann mit der Basis-Versionsnummer 4.7.0 die Tatsache, daß es sich um eine Entwicklerversion handelt (bei den stabilen Versionen lautet die zweite Stelle der Versionsnummer immer auf eine gerade Zahl), während 98.gbce83d51a9 darauf hindeutet, welchen Zwischenstand (also incl. welcher eingespielten Änderungen) man hier vor sich hat.

Und wie oben bereits erwähnt sieht man auch schön, wie groß dieses Paket dann wird (zum Zeitpunkt des Artikels über 170MB) - zum Vergleich: ein “normales” Debian-Paket beansprucht 6.3MB.

Einrichtung eines darktable-AppImage als zweite Instanz

Kommen wir endlich zur Praxis. Wie mehrfach erwähnt, soll es hier darum gehen, darktable als eine zweite Instanz für Tests oder Vergleichszwecke hinzu zu installieren (ohne die vorhandene Installation zu überschreiben!).

Verzeichnisse erstellen

Vorbemerkung: alles im Folgenden beschriebene findet im home-Verzeichnis des jeweiligen Benutzers statt, also /home/{benutzername} - als ~ abgekürzt.

Bildarchiv

Mein normales “Arbeitsverzeichnis”, in dem sich mein gesamtes Bildarchiv befindet, liegt in einem Ordner wie ~/Bildersammlung.
Um durch Entwicklerversionen dort keine “Zerstörungen” meiner normalen Arbeit zu bewirken, lege ich eine getrennte Sammlung an, diese würde analog dazu dann ~/Bildersammlung-master heißen. Und dort kopiere ich dann etliche RAW-Dateien hinein, die ich in die Enwicklerversion importiere, um damit “zu spielen” …

Ablage für AppImages

AppImages werden nicht im klassischen Sinn “installiert” und befinden sich daher auch nicht an den dafür üblichen Stellen im Dateisystem. Für diese ist daher sinnvollerweise ein “Aufbewahrungsort” einzurichten:
~/AppImages wäre ein geeignetes Verzeichnis, das hier anzulegen wäre.

Download und “Aktivierung”

  1. Das AppImage-Paket wird von der oben genannten Download-Seite heruntergeladen und im vorbereiteten Ordner ~/AppImages abgelegt.

  2. Im nächsten Schritt muß die Datei ausführbar gemacht werden, das kann im Dateimanager des Desktops passieren: Rechtsklick auf die Datei, dann “Eigenschaften”:

    =Bildbeschreibung=

  3. Und nun geht’s mit Desktop-Mitteln weiter: Je nach Desktop wird man eine Stelle finden, an der ein sog. Starter erstellt werden kann - beim Cinnamon-Desktop ist das einfach ein Rechtsklick auf den leeren Desktop:

    =Bildbeschreibung=

    Hier sind die entsprechenden Einträge vorzunehmen:

    • Der Name kann frei gewählt werden (1).

    =Bildbeschreibung=

    Und weiters unter

    • Ziffer (2): hier muß der vollständige Pfad zum AppImage eingetragen werden! Ferner ist es wichtig, hier die Optionen --configdir und --cachedir korrekt anzugeben, um zu verhindern, daß die normalen Arbeitsdaten der stabilen Version, mit der man seine Alltagsaufgaben erledigt, überschrieben und ggf. beschädigt werden.
      Der vollständige Eintrag lautet daher:
      sh -c "/home/{benutzername}/bin/appimage/Darktable-*.AppImage --configdir '~/.config/darktable-master' --cachedir '~/.cache/darktable-master'"
    • Ziffer (3) - ein frei wählbarer Text, z. B. “Entwicklerversion von darktable”
    • Ziffer (4) - hier kann das Logo von darktable eingefügt werden - ich verwende für die Entwicklerversion die etwas zurückhaltendere Variante.

    Das Ergebnis könnte dann so aussehen (der sehr lange Befehl passt natürlich nicht vollständig hier in die Ansicht):

    =Bildbeschreibung=

  4. Integration ins Startmenü: Je nach Desktop wird man beim Bestätigen der Einrichtung des Starters gefragt, ob ein Eintrag ins Startmenü erfolgen soll:

    =Bildbeschreibung=

Aktualisierung auf den nächsten Entwicklungsstand

In Punkt 3 - Ziffer (2) des letzten Abschnitts wurde ein Shell-Befehl eingetragen, damit kann man mittels einer Wildcard * (“Joker”) dafür sorgen, daß jegliches AppImage, das mit Darktable- beginnt, ausgeführt wird.
Damit ist ein Update sehr einfach und ohne weitere Zusatztools möglich:

… fertig …

Viel Spaß beim Ausprobieren der Entwicklungsstände - und dem Vorwegnehmen der nächsten Version von darktable 😄. Aber nicht vergessen: Das Projekt braucht Hilfe - also Fehler melden, an Übersetzungen beteiligen, Daten für die Unterstützung von Kameras und Objektiven beitragen … man muß nicht zwingend Programmierer sein, um an so einer tollen Software mitzuarbeiten.

1298 Worte - Lesezeit: 7 Minute(n)

 

Zu diesem Artikel

 

weitere Artikel

Bild zum Artikel

darktable und das doppelte Lottchen

07.07.2020 darktable entwickelt sich schnell weiter, und gelegentlich ist es interessant, neue zu erwartende Features schon mal vorab anzusehen und zu testen. So kann man z. B. auch schon in der Entwicklungszeit mögliche Fehler ans Projekt melden und damit die Qualität verbessern helfen. Dabei aber die eigene Arbeit mit einer stabilen Version nicht zu gefährden - darum geht es in diesem Beitrag ...

Bild zum Artikel

darktable: Backup der Daten

28.12.2017 Wie kann ich bei Verwendung von darktable mein Bildarchiv sichern?

Bild zum Artikel

Offizielle Windows-Vorabversion von darktable

09.09.2017 Das darktable-Entwicklerteam kündigt die erste offizielle Vorabversion des freien Foto-Workflow-Programms für Windows an

Bild zum Artikel

Gewitterstimmung - und die Rettung toter RAW-Dateien

03.01.2015 Beschreibung der Datenrettung bei einem Bild nach unvollständigem Kopiervorgang