Installer un nouveau logiciel : paquet .deb ou AppImage ?

cihoa · 25-08-2021 21:03:18

Bonsoir la communauté

Disclaimer : Je sais qu'il est déconseillé d'installer des logiciels hors des dépôts officiels debian mais parfois il n'existe pas d'autres solutions (par exemple je n'ai pas trouvé Veracrypt sur les dépôts officiels) et ma question aujourd'hui repose sur le scénario où l'on prend ce risque consciemment avec tout ce que ça implique.

Il m'est arrivé plusieurs fois de remarquer sur certains sites qu'un développeur propose d'installer son logiciel soit en téléchargeant un paquet deb ou en téléchargeant un AppImage.

Quelle est la méthode d'installation "la moins pire" ou "la plus optimale par rapport au système" selon vous ?

Anonyme · 26-08-2021 06:47:15

Bonjour,
Pour moi, de la pire à la meilleure :
- installer un deb qui vient d'un dépôt ppa d'Ubuntu. Conflit assuré tôt ou tard.
- installer un deb présenté sur le site du fournisseur comme valide pour Debian, Ubuntu... Je limite ça aux installations de matériel, c'est souvent plus correct que les ppa.
- installer un appimage
Je ne parle que stabilité du système, la confiance dans le diffuseur du soft compte aussi.

Herve5 · 26-08-2021 10:36:52

Anonyme a écrit :

Bonjour,
Pour moi, de la pire à la meilleure :
- installer un deb qui vient d'un dépôt ppa d'Ubuntu. Conflit assuré tôt ou tard.
- installer un deb présenté sur le site du fournisseur comme valide pour Debian, Ubuntu... Je limite ça aux installations de matériel, c'est souvent plus correct que les ppa.
- installer un appimage
Je ne parle que stabilité du système, la confiance dans le diffuseur du soft compte aussi.

Tiens, c'est curieux, perso j'aurais bien une catégorie meilleure que l'Appimage, qui serait
"deb présenté comme dédié pour Debian (pas ubuntu) sur le site du développeur, et dont je teste avec une simulation qu'il n'y a pas de conflit ni trop de dépendances à ajouter"...

La raison est double selon moi :
- le poids de l'Appimage (bien plus lourde car elle ré-embarque toutes les dépendances -mais c'est une raison faible),
- et le risque d'avoir, dans l'une de mes appimages à droite à gauche, une version de dépendance qui ne soit pas la dernière : au bout d'un moment, on a beau considérer qu'on a un système parfaitement à jour, que les appimages elles tournent dans des bacs à sable, etc. concrètement on va avoir des dépendances vieilles et bugguées, donc on fragilise le système et on ne gère plus vraiment ses versions.
Mais ça aussi, c'est une raison faible, je l'admets -Apple fait ça depuis la première version d'OSX, après tout, et ça permet d'installer une appli rien qu'en cliquant-glissant et en la posant là, tiens, voilà.

En fait, la vraie raison pour laquelle les Appimages m'inquiètent, c'est leur proximité avec les snaps d'Ubuntu.
Car c'est... presque pareil, sauf que monsieur Shuttleworth a fait évoluer sa chose d'une façon qui me terrifie : snap vire l'installateur debian* (apt) et le remplace par le magasin aux applications d'Ubuntu. Demain, tout développeur devra faire comme chez Apple ou Android : demander poliment s'il peut entrer dans le magasin, peut-être un jour en payant, peut-être aussi en te demandant d'acheter son appli en donnant un écot à monsieur S. au passage.

Cela dit, parmi les trois "empaqueteurs d'applis", Appimage est clairement le meilleur devant flatpak et snap**

(*) https://news.slashdot.org/story/20/06/0 … lashdot%29
(**) https://www.ostechnix.com/linux-package … s-flatpak/ ;

Dernière modification par Herve5 (26-08-2021 10:39:02)

cihoa · 26-08-2021 13:49:17

Je suis assez d'accord avec vous deux, je n'ai jamais été très fan d'intégrer des dépôts PPA ou de passer par ces systèmes du type Snap. Bien que sa paraisse plus simple je trouve le principe de Debian tellement "plus propre et maîtrisé" que je préfère effectivement le paquet deb classique.

Je trouverais même hyper intéressant d'avoir outil graphique qui représente le site des paquets debian ou synaptic en mindmap pour représenter visuellement les dépendances de nos programmes. Ca permettrait de voir en détails par exemple quels sont les grosses dépendances du système.

Pour le AppImage c'est exactement ce que je me disais. C'est vrai que d'un côté c'est hyper pratique et c'est le meilleur conteneur, mais il y a des petites choses dont je ne suis pas très fan. Déjà le problème de certains AppImage c'est que souvent il faut modifier la commande de lancement pour faire sauter le sandboxing sinon ça fait une erreur et ça ne se lance pas. Et ensuite effectivement sur des logiciels de sécurité comme un gestionnaire de mot de passe s'il y a des dépendances anciennes dans l'AppImage je ne suis pas fan de l'idée d'utiliser un programme avec des dépendances obsolètes (encore plus si lAppImage interagit avec le réseau).

Ensuite il y a la question des mises à jours : je n'ai jamais été fan des mises à jour automatiques que font les programmes tout seul (typiquement certains AppImage font ça maintenant) d'un côté c'est pratique mais je ne trouve pas ça optimal, je préfère garder le contrôle sur mes maintenances et prendre vraiment une demi-heure par semaine pour faire le tour du système et faire toutes les mises à jour nécessaires plutôt que d'avoir des programmes qui vérifient les mises à jour à chaque lancement et qui s'auto-maintiennent dans mon dos.

J'ai une légère obsession pour le contrôle ? nooooon ahaha

Herve5 · 26-08-2021 15:35:16

Et, au fait, il y a quand même aussi l'option de compiler soi-même les logiciels open source...
Je ne le fais pas assez souvent pour que ce soit facile pur moi, mais récemment je l'ai fait pour la dernière version de RawTherapee (traitement de photos) car leur site fait beaucoup d'efforts pédagogiques là-dessus, et même pour un logiciel complexe comme celui-là, ça marche très bien!

Yal · 26-08-2021 17:03:05

En ce qui me concerne, je dirai que la moins pire des méthodes c'est, avant d'installer quoi que ce soit hors dépôts officiels, de prendre le temps de me demander si j'ai vraiment besoin de telle version plus récente d'une application, ou même de l'application elle-même ou s'il n'y a pas une alternative ? Ça semble con mais ça aide.

La preuve ? Y a LibreOffice et Inkscape, pour lesquels je veux quand même accéder aux nouveautés. Pour LO j'ai installé les .deb de la 7.2 récupérés sur leur site. Pour Inkscape, c'est leur appimage… Mais ça reste l'exception, et si je réalise que LO ou Inkscape créent trop de problèmes, je les supprimerais pour revenir aux versions 'natives' Debian, quitte à me passer des améliorations que j’apprécie pourtant.

Perso, ce qui m'inquiète plus avec Appimage, snap et autres c'est la logique que j’y perçois (je peux me planter) : on dirait que c’est fait d’abord pour simplifier la vie du dev, mais au détriment de l'utilisateur et cela même si on le lui présente autrement : ça simplifie l’installation et les mises à jour, donc t'es plus has been avec ta vieille version du logiciel, c’est trop plus mieux.

En réalité, c’est l’utilisateur qui doit télécharger ces gros machins plein de trucs, et prendre de la place sur son disque. C’est lui aussi qui se retrouve avec une app plus ou moins bien intégrée au système (j’avais testé Gimp et je sais plus quoi, en Snap sur mon ancienne distro. Bof. pas d’intégration avec le reste, pas de support natif de mon thème et d’autres agaceries de ce genre). Et c’est l’utilisateur, encore, qui se retrouve à devoir utiliser ces versions sur son ordinateur. Or, de façon absolument pas scientifique ni quantifiée, je ne peux pas m'ôter de ma cervelle de noob que faire tourner ces nouveaux types de paquets est plus lourd et plus gourmand, donc plus pénalisant pour les utilisateurs qui ne disposent de machines performantes ou récentes.

Encore une fois, je n’ai pas de données pour étayer mon impression/mon a priori, mais je vois l’impact très concret, littéralement c'est phénoménal, sur les performances de ma machine du simple fait d’être passé de mon ancienne distribution (grand public) à une Debian. Je sens la différence au quotidien, à chaque instant que j'utilise le PC et du coup je sais l’importance capitale de ce travail manuel d’intégration et de validation des paqeuts que font les mainteneurs de Debian. Ce soin, il ne peut pas se retrouver dans un Snap ou autre.

En dehors de ça, mon côté parano ne peut pas s'empêcher de penser que ça va aller de plus en plus dans ce sens d’alourdir et de contrôler toujours plus, au nom de toujours plus de sécurité et de simplicité. Et donc de rendre de plus en plus difficile non pas d'utiliser des outils Open Source (y a bien trop de grosses boites et de pognon derrière ça) mais bien d'utiliser des outils Libre, c’est-à-dire des programmes faits en dehors du cadre de ces grosses entreprises, genre les outils GNU qui cherchent à proposer un autre modèle, une autre façon de faire.

Or, je n'ai pas renoncé au confort de Microsoft et Apple, que j’appréciais, pour me retrouver avec la même perte de contrôle sur ma machine, ni avec le même genre d’incitations à devoir renouveler mon matériel pour prétendre pouvoir rester dans la course. Mais bon, comme je disais : j’ai probablement un petit côté parano

cihoa · 27-08-2021 17:23:54

100 % d'accord avec toi Yal.

Par rapport à la lourdeur, j'ai comparé dans le gestionnaire des tâches la consommation de RAM et CPU entre un deb et un AppImage d'un même logiciel (Freetube) et je n'ai observé aucune différence.

Mais "bizzarement" je partage ton point de vue sur la lourdeur. Symboliquement je ne trouve pas ça "sain" d'avoir des dépendances dupliquées et obsolètes même si c'est empaqueté dans un AppImage. Dans la logique Debian quitte à passer pour un inquisiteur je préfère suivre les dépôts et la philosophie d'un système propre et stable.

C'est très bien vu Herve5 je n'avais effectivement pas pensé à l'option de compiler soi-même ses logiciels !
Perso je commencerai à faire ça quand j'aurais une connaissance et une habitude de veille suffisament régulière sur les logiciels et dépendances, parce que j'imagine que lorsqu'on compile soi-même il faut vérifier ensuite les compatibilités du logiciel avec ce qu'on a sur sa Debian et faire le travail aussi de compiler les dépendances à la main (enfin je crois que c'est ça non ?

).

Aujourd'hui j'ai vu un truc intéressant dans la documentation de Debian : il existe un paquet dans les dépôts officiels nommé Firejail qui permet de sandboxer des logiciels deb ou AppImage si on souhaite sécuriser leur éxécution (restreindre l'accès au réseau, l'écriture sur le disque ou d'autres choses).

Je me dis que ça peut être pas mal pour des logiciels pris "hors dépôts".

Herve5 · 27-08-2021 20:51:24

cihoa a écrit :

(...) il existe un paquet dans les dépôts officiels nommé Firejail qui permet de sandboxer des logiciels deb ou AppImage si on souhaite sécuriser leur éxécution (restreindre l'accès au réseau, l'écriture sur le disque ou d'autres choses).

Je me dis que ça peut être pas mal pour des logiciels pris "hors dépôts".

Très juste. Firejail est un must pour moi depuis longtemps. J'ai même vu un gars qui sandboxait l'installateur de Steam (puis Steam lui-même bien sûr)!
Je me souviens l'avoir fait, mais depuis un an la méthode qu'il décrit pour l'installateur ne semble plus fonctionner sur Debian 11, et je n'ai pas eu le temps d'y réfléchir... Mais clairement, Firejail est simple et parfait pour toute appli non standard, ou au code fermé. Dans la même série il y a Opensnitch, clone de Little Snitch sur mac, qui interrompt toute demande de connexion vers l'extérieur et ouvre un dialogue permettant de l'interdire, de l'accepter cette fois, ou de l'accepter définitivement, avec une granularité très fine (autoriser vers cette seule url ou plus, etc.)

cihoa · 27-08-2021 23:22:57

Très intéressant, je recherchais justement quelque chose de plus interactif que ufw

Croutons · 28-08-2021 08:02:32

cihoa a écrit :

Très intéressant, je recherchais justement quelque chose de plus interactif que ufw

gufw peut être

Jean-Pierre Pinson · 12-04-2024 12:21:44

Je n'utilise pas Snap, flatpak, PPA, appimages......
Seul les les .deb provenant des dépots debian officiels méritent ma confiance. ?

Dernière modification par Jean-Pierre Pinson (12-04-2024 12:22:35)

Trefix · 12-04-2024 21:29:47

Je ne peux pas me passer de l'appimage de MuseScore vu le boulevard entre version des dépôts Bookworm et dernière version stable du logiciel... Woui, même avec les sources bookworm-backports

Jean-Pierre Pinson · 12-04-2024 21:43:13

Trefix a écrit :

Je ne peux pas me passer de l'appimage de MuseScore vu le boulevard entre version des dépôts Bookworm et dernière version stable du logiciel... Woui, même avec les sources bookworm-backports

Qu'est-ce que l'appimage de MuseScore t'apporte de plus que la version des backports ?

Trefix · 13-04-2024 07:13:27

MuseScore4 contre MuseScore3, avec un sacré saut technique entre les deux.

Plus le fait de travailler avec des collègues zindoziens et makystes, d'où des problèmes idiots lors d'échanges de fichiers : il y a une rétro-compatibilité mais pas d'anté-compatibilité.

Et vu la lenteur désespérante avec laquelle les upgrades de version arrivent dans les backports, ce n'est manifestement pas le logiciel le plus utilisé par la communauté Debian

Résumons : sur le fond je suis (presque) d'accord avec ta position. Dans les faits, mes besoins professionnels me conduisent à l'alternative AppImage ou W$ (en dual boot ou pire sur une machine dédiée).

Le "presque", enfin : la sécurité est utilisée ad nauseam comme prétexte à la limitation institutionnelle des libertés publiques. Je fais beaucoup d'efforts pour limiter au quotidien l'emprise du capitalisme de surveillance sur ma vie et éviter autant que faire se peut la course au "progrès" inutile, mais je n'ai pas de solution pour en sortir complètement. J'observe et soupèse très souvent cette "alternative" forcée entre liberté et sécurité, ce qui me confirme régulièrement que nous avons été privés malgré moi de nombreux leviers d'action. Je milite activement pour le choix libre et éclairé.

Édith précise pour les versions de MuseScore :
3.2.3 dans sid -> Stable (2019-07-09)
3.6.2 dernière AppImage de 3 et fin de support pour W$ 32 bits (2021-02-08)
4.0 (2022-12-14)
4.2.1 sortie en même temps pour W$ 64bits, Mac et en AppImage... (2024-01-24).
.

Dernière modification par Trefix (13-04-2024 10:29:32)

vv222 · 13-04-2024 14:04:21

Trefix a écrit :

Et vu la lenteur désespérante avec laquelle les upgrades de version arrivent dans les backports, ce n'est manifestement pas le logiciel le plus utilisé par la communauté Debian

À ma connaissance, Musescore (2 comme 3) n’a tout simplement jamais fait partie des backports pour Bookworm.

Trefix · 13-04-2024 15:16:28

Il y a trèèèès longtemps que j'utilise MuseScore et j'ai donc régulièrement surveillé les backports de mes différentes Debian stables en espérant le miracle.

Puis je me suis résolu à passer à l'AppImage quand l'évolution d'une version à l'autre s'est nettement accélérée (fin de la version 2 et bascule en 3), avec des gains réels et sensibles à mon petit niveau (je l'utilise toutes les semaines avec quelques sessions mensuelles de 6 à 12 heures pièce, pour chœur et/ou orchestre, donc "un peu" quand-même). Et évidemment à cause des difficultés de compatibilité quand on travaille entre collègues, comme déjà évoquées.

Actuellement les dépôts de Bookworm stable ont la même version que Sid, version âgée de 4 ans 8 mois... Et plus d'un an après la sortie de la 4 il n'y en a pas trace chez Debian. Ça ne signifie pas que personne ne s'y intéresse chez les dev, mais que pour le miracle d'une version récente dans les dépôts, ben...

Comme mon épouse est bloquée à la 3.6.2 (un jour je la convaincrai enfin de virer son W$ 10 32bits), très supérieure à la 3.2.3, je mesure l'accroissement de l'écart au fil des MàJ à chaque fois que j'utilise sa version (souvent quand elle "coince" sur un truc, l'utilisant assez rarement).

Je choisi donc le risque (?) d'une AppImage régulièrement mise à jour pour éviter les pesanteurs d'usage d'une version .deb vérifiée comme sûre mais nettement dépassée (avec un son de m... au passage), moins fluide, moins souple et moins rapide d'usage pour un utilisateur régulier.

Et pour le reste (sauf Audacity et yt-dlp) je tourne en stable et ça me contente parfaitement pour l'usage que j'en ai.

Il me semble que ça peut constituer un bon exemple de choix réfléchi, pas trop dogmatique.

vv222 · 13-04-2024 15:29:19

Trefix a écrit :

Et plus d'un an après la sortie de la 4 il n'y en a pas trace chez Debian. Ça ne signifie pas que personne ne s'y intéresse chez les dev, mais que pour le miracle d'une version récente dans les dépôts, ben...

À moins que je l’ai manquée, aucune demande n’a jamais été faite pour l’intégration de MuseScore 4 chez Debian. Ce qui laisse entendre qu’elle n’intéresse dans la pratique ni les mainteneurs, ni les utilisateurs de Debian.

Trefix · 13-04-2024 15:31:04

Ha ? Il suffisait de demander ???

Ou que les rares debianistes utilisateurs ont fait comme moi et opté pour une AppImage qui marche bien au lieu d'attendre, attendre, attendre...

Dernière modification par Trefix (13-04-2024 15:32:48)

vv222 · 13-04-2024 16:04:18

Trefix a écrit :

Ha ? Il suffisait de demander ???

Bien sûr, c’est comme ça que de nouveaux paquets intègrent les dépôts.
L’état des différentes demandes en cours peut être suivi sur https://wnpp.debian.net/.

Trefix a écrit :

au lieu d'attendre, attendre, attendre...

Ils peuvent continuer à attendre très longtemps. Sans aucune marque d’intérêt de la part des mainteneurs et utilisateurs, MuseScore 4 n’a aucune chance d’intégrer les dépôts.

Trefix · 14-04-2024 08:20:19

Bonjour.

Comme les versions 2 puis 3 entraient (lentement) dans les dépôts, je pensais naïvement que le suivi du logiciel était acté. Je me doute bien que la demande pour un logiciel qui était à l'époque exclusivement orienté vers l'écriture de partitions (musicales) ne dois pas être folle, donc ne mobiliser que peu de ressources (dev)...

Or le développement du logiciel s'est nettement accéléré et les problèmes d'interopérabilité se sont révélés (pour moi) à l'occasion de gros projets, précisément au moment où Sid et Stable se sont retrouvés sur la version actuelle.

La position du militant était de rester sur le *.deb mais celle de l'utilisateur, contraint d'échanger des exports/imports en *.xml pour travailler avec des collègues, avec le même logiciel, n'est pas restée tenable très longtemps.

Puisque Debian Packages ne montrait pas de version supérieure dans Sid, la solution a été l'AppImage, qui plus est proposée par l'éditeur simultanément aux versions W$-Mac à chaque update.

Bref, ça me semblait bien illustrer (pour aller dans le sens du titre du fil) le dilemme de l'utilisateur lorsque ses besoins dépassent largement les contraintes liées à la politique de prudence et de stabilité de Debian.

Du coup, je résumerais ma position ainsi :
- nouveau logiciel signifie nouvel usage, donc installer le .deb avec apt est sans risque et le cas échéant pourra être "nettoyé" facilement,
- si l'utilité invite à monter en version et que les backports le permettent, méme conclusion, ça suffit pour la majorité des utilisations occasionnelles,
- mais si le "retard" de version devient problématique l'AppImage présente alors une alternative acceptable, au moins temporairement (ou pas, ici, hélas).

Pour le reste de l'argumentation technique, je n'ai pas les compétences pour trancher. D'une manière générale je préfère toujours les FOSS car je postule que d'autres que moi les ont, les compétences, pour s'assurer de la relative innocuité de l'outil que j'utilise. Et comme je ne veux pas de *.exe, je suis parfois amené à faire des compromis...

Herve5 · 15-04-2024 19:55:34

Juste pour mémoire, la version .deb qui se trouve sur le site de Musescore, ce n'est pas la dernière?
(les deux boutons en bas ci-dessous)

Trefix · 16-04-2024 07:36:31

Bonjour.

Ce .deb est assez nouveau (postérieur à la v4) et c'est un "faux deb" car cette partie complémentaire (gestionnaire de banques de sons additionnelles) n'a pas de sources consultables :

https://musescore.org/en/node/358231

Quant au logiciel d'écriture, aka MuseScore 4.2.1 | Linux (GPL v3) le lien lance exclusivement le téléchargement de la dernière version de l'AppImage, sans alternative, fût-ce un format *.deb "usine" (comprendre venant de Muse Group). Il y aurait peut-être des sources accessibles du côté des nightly (4.3), mais là c'est du dev. pour lequel je n'ai pas les compétences.

Qu'ils aient choisi de proposer "leur" *.deb pour l'extension, en version bêta, signe peut-être une volonté de modifier leur implantation sur le marché, relativement à la niche GNU/Linux... En bien ???
.

Dernière modification par Trefix (16-04-2024 09:12:24)

Debian-facile

#1 25-08-2021 21:03:18

Installer un nouveau logiciel : paquet .deb ou AppImage ?

#2 26-08-2021 06:47:15

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#3 26-08-2021 10:36:52

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#4 26-08-2021 13:49:17

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#5 26-08-2021 15:35:16

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#6 26-08-2021 17:03:05

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#7 27-08-2021 17:23:54

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#8 27-08-2021 20:51:24

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#9 27-08-2021 23:22:57

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#10 28-08-2021 08:02:32

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#11 12-04-2024 12:21:44

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#12 12-04-2024 21:29:47

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#13 12-04-2024 21:43:13

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#14 13-04-2024 07:13:27

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#15 13-04-2024 14:04:21

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#16 13-04-2024 15:16:28

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#17 13-04-2024 15:29:19

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#18 13-04-2024 15:31:04

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#19 13-04-2024 16:04:18

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#20 14-04-2024 08:20:19

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#21 15-04-2024 19:55:34

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

#22 16-04-2024 07:36:31

Re : Installer un nouveau logiciel : paquet .deb ou AppImage ?

Pied de page des forums