Un retour d’expérience de l’utilisateur très peu avancé de darktable que je suis :
Comme le dit jpg 54 « Les versions 4.6.1 pour les distributions ne sont toujours pas sur : https://software.opensuse.org/download.h…=darktable", j’ai franchi alors directement le pas il y a deux jours vers la version master 4.7 avec darktable from graphics:darktable:master project.
Aucun problème à l’installation. Juste une fenêtre qui s’est ouverte pour me demander de mettre ma base de donnée à jour.
Ce que j’ai fait juste en cliquant sur un bouton.
Depuis, j’ai noté que le petit message casse-pied à l’ouverture pour me parler de l’open cl (je ne l’ai pas sur ma carte graphique) n’apparaît plus.
J’ai pu aussi essayé un module inconnu pour moi " Égaliseur de couleurs ».
Il est très efficace et assez ergonomique.
Et j’ai pu voir que les développeurs bossaient tous les jours. Encore un grand merci à eux.
Car depuis, tous les jours, mon système me notifie une nouvelle mise à jour pour cette version master.
D’accord aussi avec jpg54 pour éviter les flatpak ainsi que les snap d’ailleurs.
Ce n’est pas moi qui saurait vous expliquer techniquement pourquoi, mais je sais que j’en ai pas de bons souvenirs.
FlatPak est un système à la Windows qui embarque son environnement, donc les librairies (comme AppImage). Si deux programmes utilisent les mêmes librairies dans chaque environnement en version identique ou différente !
Suivre le développement de master permet de compiler toutes les ressources spécifiques à son système, mais s’expose à quelques dysfonctionnements qui sont souvent réglés rapidement par les développeurs aussitôt qu’ils sont signalés sur : https://matrix.to/#/#dev_darktablefr:matrix.org
C’est bien sûr ce que j’utilise avec 2 config : un pour la version stable et l’autre pour la master. Parfois les config sont incompatibles et de plus, si l’on veut partager des traitements parfois ceux de la master ne peuvent être utilisés par la version stable.
Effectivement, j’ai demandé aux développeurs si l’on peut se rabattre sur la version FlatPak il y a 3 jours et toujours pas de retour. Comme je l’ai toujours dit, je ne suis pas fan des versions FlatPak, AppImage et consorts ! Je l’ai installé sous OpenSuse Tumbelweed sans problème. Il semble que le problème de l’absence de l’OpenCL semble réglé et j’y ai accès avec la version que j’ai installée. J’ai vu sur : https://discuss.pixls.us/t/darktable-flatpak-running-slower-than-deb-install/42358/22 qu’il peut y avoir des problèmes de rapidité : mais peut-être avec la carte de l’utilisateur.
Fondamentalement il n’y a qu’un aspect qui diffère d’une distribution à l’autre, le système de paquetage les dépôts qui vont avec et son gestionnaire pour installer les applis et les mettre à jour. Le reste n’est qu’un choix de bureau, et d’applications proposées par la distribution. Mais toutes les distributions majeures offrent le bureau de son choix, les applis connexes qui vont avec.
Autrement dit pour les pressés, ou du moins ceux qui souhaitent profiter de la dernière version des applis cherchez du coté des distributions rolling release.
Ce n’est pas faux mais tu devrais voir arriver les binaires de la 4.6.1 rapidement, du moins plus vite que d’autres systèmes de paquets.
Il faut laisser le temps aux mainteneurs de paquets de faire leur job.
D’ailleurs sur ma propre distribution la 4.6.1 n’est pas plus disponible, probablement dans la prochaine stable-update dans la quinzaine à venir.
Et il est vrai que j’utilise la master sous Linux compilée quasi journellement à partir du PKGBUILD AUR, donc toujours à jour.
Actuellement le disponible sur un système Arch Linux ou dérivé
J’utilise aussi la master compilée avec un config spécifique, j’ai aussi essayé la version 4.6.1 en FlatPak bien que je ne suis pas un fan. La 4.6.1 n’est pas disponible pour ma distribution (le mainteneur est aussi celui qui celles pour Debian, Fedora et Ubuntu !) :
Ceci expliquant cela, car c’est récurrent tous les six mois le sujet s’ouvre ici pour ces distributions… et dure parfois longtemps.
Le problème étant que les fiottes de la Debianterie sont nombreuses.
Ça c’est au moins un avantage coté Arch Linux, le PKGBUILD… la recette pour compiler… est disponible et quand bien même le paquet n’est pas prêt sur les dépôts en une petite modif du dit fichier on peut le compiler en local (sauf grosses modifications, ajout ou retrait de dépenses, mais même ce n’est pas si compliqué à modifier)
J’ai toujours en projet de faire le PKGBUILD pour Xpano, j’ai une version qui fonctionnerait presque à l’exception d’une dépendance qui me résiste à la compilation (elle comme beaucoup de dép de cette appli sont absentes des dépôts)
Oui ben c’est toujours la même chose.
Soit tu te cognes les commandes en terminal les unes derrières les autres
Soit tu en passes par un script, ce qui est plus funky
Et la différence entre la release et la master n’est qu’une question de sources, les actions pour compiler restent standards.
Donc effectivement tu pourrais te faire un script pour la release en modifiant celui de la master.
Les PKGBUILD sous Arch, sont aussi en quelque sorte un fichier texte donnant les informations pour la compilation, voire compilation des dépendances si un ou plus de paquets dépendants ne sont pas dans les dépôts, installation de l’appli, insertion dans le système et suivi des MàJ,
Raison pour laquelle j’ai journellement une voire deux MàJ de la master (c’est paramétrable si on souhaite ralentir le rythme).
Le PKGBUID de la release (dépôt Extra) et le PKGBUILD de la master (AUR) pour voir les dif… souvent un peu plus bricolé voire pas trop regardant sur les md5sums
Mais on utilise en connaissance de cause :rolleyes:
