Installation de darktable

Pourquoi compiler darktable ?

j’y trouve deux raisons actuellement. La première est d’avoir la version stable le plus rapidement dès la sortie. En effet, packager dépend encore du temps disponible de chaque contributeur sur les différentes distributions. La compilation permet de ne dépendre que de soi-même. La deuxième est de pouvoir tester la version en développement.

Pour la version en développement, il est toujours possible de passer par un dépôt tiers. Outre la difficulté de savoir si ils sont sécurisés correctement, la principale réside dans l’impossibilité relative de revenir en arrière si une fonctionnalité dysfonctionne ; ce qui est possible avec un dépôt git, un autre intérêt de la compilation. On peut parler de relatif car il est aisé de revenir en arrière uniquement si on possède encore le paquet précédent. Il n’y a pas de problème d’hypothèse d’avoir le paquet précédent avec le dépôt.

Il y a quelques précautions à prendre tout de même :

• avoir des sauvegardes de la base de données régulières de sorte que si darktable ne démarre plus et qu’il y a eu une mise à jour de la base de données, il soit possible de revenir en arrière.
• démarrer sur des bases de données différentes si il existe plusieurs darktables sur la machine. Il est possible d’avoir sur sa machine darktable en version stable et en version de développement avec l’attention qu’il existe 2 collections d’images. La même photo physique ne peut être sur les deux versions.

Comment compiler et installer une première fois ?

Je ne reviendrais que peu dessus, il existe un excellent article de Nicolas Tissot ; il n’y a pas besoin de réinventer la roue : Compilation de darktable.

A ne pas oublier :

• compiler
• ne pas mélanger les bases de données si plusieurs darktables

Sauvegarde de la base de données

Pour cela, borgbackup est une solution idéale. Versionner la base de données ne prend que peu de place. Je vous laisse le soin de lire le détail sur la page docs.

Il est nécessaire de faire une sauvegarde dès que l’on change de version, juste avant la compilation. Pour ma part, je sauvegarde sur un nas maison sous un raspberry pi zéro W et je lance, en plus, des sauvegardes automatiques toutes les trois heures.

Revenir en arrière sur la base de données

Il suffit de monter comme une clé usb la dernière version de la base de données sur un emplacement et de remplacer le contenu du dossier config par le contenu monté. Cela sert quand darktable met à jour la base de données mais qu’il bugge. Comme les versions de darktable antérieures ne supportent pas le nouveau format de la base de données, il faut revenir en arrière.

Il suffit de :

• lister les sauvegardes pour trouver celle que l’on veut avec

  borg list /repo

• monter celle voulue avec

  borg mount /repo dossier

• et enfin copier le contenu pour écraser le contenu du dossier config

Revenir à la version darktable qui se lance

Pour revenir en arrière quand le “nouveau” darktable bugge, il suffit de recompiler dans la dernière version qui fonctionne. Si la base de données a été modifiée, il sera possible de revenir aussi en arrière comme écrit précédemment.

Dans un premier temps, il faut être dans le dossier git qui a été créé lors de l’installation et compilation de darktable.

La commande qui sera utilisée est :

git checkout numéro-commit

Pour trouver le numéro, il faut se rendre sur le site du dépôt git à savoir dépôt darktable, de cliquer sur le numéro court du commit.

Il suffira ensuite de copier le numéro long dans la commande

git checkout numéro-commit

Il suffira de relancer le script de compilation pour avoir un darktable “ancien” mais qui fonctionne.

Synthèse avec un script

En dehors des bugs qui peuvent parsemer le développement, darktable se lance assez bien dans cette version “béta”. Il peut donc être intéressant de scripter cette sauvegarde, mise à jour du dépôt git et compilation de darktable. C’est ce que j’ai fait, voici le mien :

#!/bin/bash

cd ~
echo -e "\033[31mSauvegarde et compilation de dt\033[0m"

cd git-darktable/
git pull
git submodule init
git submodule update

cd ~
borg create --compression lzma,9 /repo::{now} /home/guillaume/.config/darktable_master/

sudo rm -R /opt/darktable_master/


cd git-darktable/
sudo rm -R build/
./build.sh --prefix /opt/darktable_master/ --build-type Release
sudo cmake --build "/home/guillaume/git-darktable/build" --target install -- -j6

Le /repo doit vous correspondre et donc peut être modifié. Le script est à placer dans le dossier bin/ et avoir les droits pour pouvoir être lancé depuis le terminal ; assez pratique.

Ansel

On peut appliquer certains principes à Ansel. Ainsi, prendre la version compilée est avantageuse et permet de contrôler les emplacements, notamment des fichiers de configuration.