Témoignages et avis flatpak sur Debian

[Aka_de_Kebnekaise]

Bonjour ! J'utilise actuellement Ubuntu 22.04 sur mon ordinateur principal, mais je vais bientôt passer à Debian après l'avoir testé longuement sur un autre ordinateur portable.

Je fais ce choix pour (ordre non hiérarchique) :

• la stabilité (Ubuntu crash trop souvent)

• la philosophie de Debian et un mode de fonctionnement + en accord avec l'idée que j'ai du logiciel libre

• je n'ai pas besoin d'avoir les super mega nouveaux derniers outils modernes dès leurs sorties, seulement certains qui sont intégrés à Debian avec cette 12e version

• soutenir et prendre part (au moins d'abord en tant que simple utilisateur) au projet Debian

Pour ce qui est des paquets et applications : je prévois de prioriser tout paquet existant dans les dépôts de bookworm. Sinon de chercherai une alternative présente dans ces dépôts. Je prévois quelques exception comme pour le client de synchronisation de mon cloud (appimage), mon VPN et Minecraft (!). De n'utiliser AUCUN snap. De ne pas compiler de paquet (je veux garder mon système propre et ne pas le transformer en Frankenstein).

En revanche en ce qui concerne les Flatpaks : j'utilise actuellement un certains nombre d'applications provenant de Flathub, en flatpak donc.
Je prévois certes de faire le tri parmi celles que j'utilise.
Mais je pense tout de même utiliser quelques applications flatpak sur Debian. Je pense notamment à Tenacity (fork d'Audacity sans les outils intrusifs de Muse Group et qui n'est pas dans les dépôts), FreeTube que j'aime bien ou quelques gadgets bien intégrés à GNOME et que je trouve sympas.

Mais je voulais savoir ce que vous en pensiez. Je ne crois pas risquer la Frankenstein, mais peut-être avez-vous un autre avis. Aussi : devrais-je prioriser pour les apps non présentes dans les dépôts : le fichier appimage, le paquet .deb provenant du net, ou l'app flatpak ? Qu'est-ce qui est le mieux pour ne pas casser Debian ?

Aka

[vv222]

Rejeter snap mais utiliser flatpak ? Il y a une partie du raisonnement qui m’échappe.
Je ne vois pas non plus ce que la mention de compilation vient faire au milieu de tout ça.

Si ce que tu veux c’est ne pas finir avec une Frankendebian, il faut utiliser 0 snap, 0 flatpak, 0 appimage. Uniquement des .deb, uniquement depuis les dépôts officiels Debian, sans mélanger les branches de Debian.

[dezix]

Sans contredire le moins du monde ce qu'a écrit @vv222

si malgré tout tu décides d'utiliser des flatpacks,
alors peut-être le faire dans un environnement restreint <=> Bac à sac <=> Prison ....

Je sais (sans l'avoir utilisé) que firejail permet cela pour AppImage,
il existe peut-être une équivalence pour FlatPack

[Aka_de_Kebnekaise]

Rejeter snap mais utiliser flatpak ? Il y a une partie du raisonnement qui m’échappe.
Je ne vois pas non plus ce que la mention de compilation vient faire au milieu de tout ça.

Eh bien, je me disais que c'était moins pire Mais je suis très hésitant, et ce que tu me dis me pousse plutôt à me passer des flatpaks.

Pour ce qui est de la mention de la compilation, j'ai lu que c'est déconseillé pour éviter une Frankendebian dans cette page de forum-debian.fr : viewtopic.php?t=584

Voici un extrait :

Ne pas faire de « make install »

Il est assez facile de compiler un logiciel depuis son code source téléchargé sur le site du logiciel, mais pas toujours aussi facile de le désinstaller plus tard. Souvent, les instructions fournies avec le code source comprennent des instructions pour utiliser des commandes comme ./configure && make && make install.

Lorsque vous installez le logiciel de cette façon, vous ne serez plus en mesure de l'enlever avec apt-get ou Synaptic. Le gestionnaire de paquets APT ne peut supprimer que les logiciels qui ont été installés par le gestionnaire de paquets APT. Pire encore, les logiciels installés de cette façon peuvent parfois entrer en conflit avec les logiciels empaquetés pour Debian.

Les logiciels installés de cette façon ne bénéficient pas des mises à jour de sécurité dont les paquets Debian ont besoin. Si vous voulez garder votre système à jour sans avoir à compiler et réinstaller pour chaque mise à jour manuellement, utilisez exclusivement les paquets fournis dans les dépôts Debian.

--

Je sais (sans l'avoir utilisé) que firejail permet cela pour AppImage,
il existe peut-être une équivalence pour FlatPack

Oui c'est ce que je me disais. Il existe Flatseal pour gérer les permissions et le bac à sable des flatpaks installés. Mais bon... je ne suis plus sûr d'utiliser de flatpaks

Uniquement des .deb, uniquement depuis les dépôts officiels Debian, sans mélanger les branches de Debian.

Oui voilà aussi : je prévois en effet de ne pas mélanger les différentes branches de Debian. Mais donc si je comprends bien : tu me déconseille également d'installer des paquets .deb fournis par leurs développeurs (genre ProtonVPN qui fournissent leur app pour Debian avec un paquet .deb, non présent dans les dépôts...) ?

Aka

[vv222]

Ne pas utiliser "make install", ça ne veut pas dire de ne pas compiler de logiciel depuis ses sources

À savoir que le message que tu mets en lien est particulièrement vieux, et basé sur un article de wiki qui était déjà plutôt périmé au moment où ce message a été posté ici.

[Aka_de_Kebnekaise]

Ne pas utiliser "make install", ça ne veut pas dire de ne pas compiler de logiciel depuis ses sources

Je dois dire que je ne m'y connais vraiment pas en compilation Je m'éloigne peut-être un peu du sujet de ce post, mais... ça veut dire qu'on peut compiler un logiciel depuis autre chose que ses sources ?! mais alors depuis quoi ?
(je pensais que compiler ça voulais dire "créer" ou plutôt "transformer" le code source d'un logiciel en application exécutable.

Mais alors : est-ce une bonne solution pour éviter d'utiliser les flatpaks : compiler un logiciel depuis ses sources et hop! le problème est reglé! Ou bien je me trompe?

Dites-moi,
Aka

---
Edit :
Je viens de lire de la documentation, si je comprends bien : utiliser make install installe le logiciel directement, alors que make puis checkinstall permet de créer un paquet .deb qui pourra servir à faciliter la désinstallation (plus proprement).

Mais une question persiste : est-ce que la compilation est une bonne solution pour éviter d'utiliser les flatpaks ET pour éviter d'obtenir une Frankendebian ?

[vv222]

Mais une question persiste : est-ce que la compilation est une bonne solution pour éviter d'utiliser les flatpaks ET pour éviter d'obtenir une Frankendebian ?

Pour éviter les flatpaks oui.
Pour éviter d’obtenir une Frankendebian non.

Si tu veux utiliser une Debian "pure", tu dois :

• N‘installer de logiciels que depuis les dépôts Debian ;
• N’utiliser que la branche stable de Debian (actuellement Bookworm), sans backports ;
• Ne pas utiliser de section des dépôts en-dehors de "main" (donc pas de "non-free", pas de "contrib", pas même de "non-free-firmware") ;
• Si un logiciel n’est pas disponible de cette manière, il faut s’en passer.

À toi de voir si c’est vraiment ce que tu souhaites, ou si tu es prêt à des compromis

[Aka_de_Kebnekaise]

Oui je vois. Je comprends bien maintenant ce qu'implique toute installation d'un logiciel ne provenant pas des dépôts.

Je pense que je suis prêts à faire des compromis pour adopter dès le début une bonne utilisation de Debian, pour ce qui est des logiciels que j'utilise aujourd'hui et qui ne sont pas dans les dépôts : je pense que je peux me passer facilement d'une très grande majorité d'entre eux. Pour les autres : je chercherai des alternatives, puis j'aviserai.
Mais c'est clair que je veux garder un système clean.

Merci beaucoup pour l'aide et les explications que vous m'avez apportés !
Aka

[Grhim]

slt,

juste pour rappeler qu'il existe un outils automatique pour installer les .deb , gdebi il désinstalle aussi proprement..

[franb]

Hum, que reprochez vous aux appsimage par exemple. Très souvent fondé sur debian, elles permettent d'utiliser des variantes de logiciels sans polluer l'environnement. Ci dessous, un exemple d'une variante de qpdfview dont j'avais les paquets (introduction d'un chiffrage spécifique pour des raisons de confidentialité), cela me permettait de conserver le qpdfview original et d'avoir la variante en même temps.

Code : Tout sélectionner

app: qpdfview
  binpatch: true

ingredients:
  dist: buster
  sources:
    - deb http://ftp.debian.org/debian/ buster main contrib non-free
    - deb [trusted=yes] http://www.deb-multimedia.org stable main non-free
  debs:
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview_0.4.17~beta1+git20180709-3agreg_amd64.deb
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview-djvu-plugin_0.4.17~beta1+git20180709-3agreg_amd64.deb
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview-djvu-plugin-dbgsym_0.4.17~beta1+git20180709-3agreg_amd64.deb
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview-ps-plugin_0.4.17~beta1+git20180709-3agreg_amd64.deb
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview-ps-plugin-dbgsym_0.4.17~beta1+git20180709-3agreg_amd64.deb
    - /home/francois/ownCloud/Agreg2021/Biblio/qpdfview-translations_0.4.17~beta1+git20180709-3agreg_all.deb
  script:
    - mkdir -p qpdfview.AppDir
    - cp ../qpdfview.png qpdfview.AppDir

post_script:
    - mkdir -p usr/share/icons/hicolor/scalable/apps
    - (cd usr/share/icons/hicolor/48x48/apps ; ln -sf /usr/share/icons/hicolor/48x48/apps/qpdfview.png)
    - pwd
    - (cd usr/bin ; for i in libqpdfview_djvu.so  libqpdfview_image.so  libqpdfview_pdf.so  libqpdfview_ps.so ; do ln -sf ../lib/qpdfview/$i ; done)

Ça permet également de faire tourner des vieux logiciels sur du récent. Les dockjers constituent une alternative efficace mais bcp plus encombrante, j'ai pu faire tournée comme ça un logiciel plafonnant à woody/i386 sur ma machine.
Honnetement j'ai du mal à voir le souci, les namespaces sont fait pour ça justement

[vv222]

Hum, que reprochez vous aux appsimage par exemple.

La même chose que je reproche à toute forme de distribution se basant sur des bibliothèques liées statiquement : contrairement à la promesse annoncée, ça ne fonctionne pas partout. Si le système est trop vieux ou trop récent, ça a tendance à se vautrer.

Contrairement à un système similaire mais utilisant des liens dynamiques, c’est très difficile à corriger localement dans le cas de binaires statiques.

Ici par exemple je peux encore faire tourner Alpha Centauri (binaires construits en 2000) sur une Debian Trixie/Sid grâce aux binaires dynamiques fournis, alors que les binaires statiques ne permettent plus de lancer ce jeu depuis longtemps.

[franb]

Oui et non, tu peux intégrer à une appsimage des vieilles librairies qui prennent le pas sur les librairies utilisées. En gros, les appsimages sont initialement prévus pour un usage temporaire ou bien des corrections de ponctuelles de librairies existantes, mais tu peux mettre bcp de librairies obsolètes dans une appsimage pour un vieux logiciel: Il te suffit pour cela de commenter la ligne

Code : Tout sélectionner

delete_blacklisted

dans le programme pkg2appimage
Le procédé a ces limites, pour un pgm datant de trop longtemps, il vaut mieux privilégier un docker.
Pour les applications propriétaires, c'est aussi une bonne solution

[vv222]

tu peux intégrer à une appsimage des vieilles librairies qui prennent le pas sur les librairies utilisées.

C’est le cœur du problème pour moi. Un fois que le développeur à décidé que son logiciel devait tourner sur la version X d’une bibliothèque donnée, on ne peut plus le faire tourner avec quoi que ce soit d’autre. Le jour où cette version X embarquée ne tourne plus (par exemple à cause d’une mise-à-jour de la lib C GNU) cette AppImage n’est plus qu’un presse-papier virtuel.

Si vraiment on veut fournir des bibliothèques dans des versions précises, on a déjà accès à LD_LIBRARY_PATH pour ça. Qui a l’énorme avantage de laisser le contrôle final à l’utilisateur, pas au développeur.

En gros, les appsimages sont initialement prévus pour un usage temporaire ou bien des corrections de ponctuelles de librairies existantes

Si c’était l’utilisation majoritaire des AppImages, je n’aurais rien à reprocher à ce format. Malheureusement c’est dans beaucoup de cas le seul format de distribution d’un logiciel.

[franb]

tu peux intégrer à une appsimage des vieilles librairies qui prennent le pas sur les librairies utilisées.

Si vraiment on veut fournir des bibliothèques dans des versions précises, on a déjà accès à LD_LIBRARY_PATH pour ça. Qui a l’énorme avantage de laisser le contrôle final à l’utilisateur, pas au développeur.

Sur ce plan, je préfère plutôt modifier le rpath et le lanceur du elf, c'est beaucoup plus simple et évite de dépendre des variables d'environnement. Sinon il est très facile de détricoter une AppsImage, en fait elle est composée d'un lanceur et d'une image squashfs contenant l’arborescence du pgm. Pour moi, c'est une solution idéale pour un logiciel propriétaire pour éviter qu'il pollue ton système

[dezix]

Une question de candide :

Pour moi, c'est une solution idéale pour un logiciel propriétaire pour éviter qu'il pollue ton système

Récemment,
il a été fait mention dans ce même forum de l'installation de matlab
via cette commande :

Code : Tout sélectionner

xhost +SI:localuser:root sudo -H ./install
xhost -SI:localuser:root

Est-il compliqué d'en faire l'install dans une AppImage ?

Si vous avez un bon tuto à mettre en lien... n'hésitez pas

[franb]

Le souci est que si il est facile de faire une AppsImage avec des paquets debian sur une distribution données, pour les propriétaires c'est du cas par cas qui nécessite un petit travail en général. J'ai pu faire ça pour Hopper (dont je me sers réellement), Maple14 (que je n'utilise pas mais qui est typique des difficultés: java différents, truc vieux, et librairies diverses à charger dont je dois dire une me permettant de l'utiliser si je veux). Ça doit être faisable pour Matlab

[dezix]

Je ne vais pas me lancer dans ce domaine maintenant (pas de besoin actuellement),
j'ai survolé très rapidement le site du projet et wikipedia sans y trouver le (schématique) principe

C'est comme pour un conteneur ?... on construit l'application et ses dépendances dans un chroot (rootfs) pour générer le fichier "AppImage" ?

ou c'est un principe différent ?

[vv222]

Sinon il est très facile de détricoter une AppsImage, en fait elle est composée d'un lanceur et d'une image squashfs contenant l’arborescence du pgm.

Je connais assez bien cette architecture, j’avais étudié les AppImage pendant un moment. Mais quand je me suis rendu compte qu’on ne peut pas utiliser un runtime indépendant pour extraire le contenu de l’image (il faut impérativement exécuter la partie binaire intégrée) j’ai abandonné l’idée de les prendre en charge.

[franb]

Je connais assez bien cette architecture, j’avais étudié les AppImage pendant un moment. Mais quand je me suis rendu compte qu’on ne peut pas utiliser un runtime indépendant pour extraire le contenu de l’image (il faut impérativement exécuter la partie binaire intégrée) j’ai abandonné l’idée de les prendre en charge.

Pour info

Code : Tout sélectionner

[/tmp]$ binwalk xmaple14.AppsImage 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
144832        0x235C0         SHA256 hash constants, little endian
145304        0x23798         xz compressed data
145344        0x237C0         CRC32 polynomial table, little endian
193704        0x2F4A8         Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 286670869 bytes, 1571 inodes, blocksize: 131072 bytes, created: 1970-01-01 00:00:00

[/tmp]$ tail -c +193705 xmaple14.AppsImage > dsk
[/tmp]$ sudo mount -o loop -t squashfs dsk /mnt
[/tmp]$ ls /mnt
AppRun  maple14.desktop  maple14.desktop~  maple14.png  usr
[/tmp]$ 

[vv222]

Je n’avais pas pensé à utiliser un outil comme binwalk pour récupérer les valeurs des offsets, c’est bien vu !

Reste à voir si on peut récupérer le contenu d’une image squashfs sans passer par mount/root/fuse (on peut probablement le faire, faut juste que je fouille un peu) pour que je considère enfin les AppImage comme un simple format d’archive un peu tordu. Ça permettrait en particulier d’enfin les prendre en charge avec ./play.it, pour une conversion automatisée AppImage → .deb.