Vous n'êtes pas identifié(e).
Un snap "mieux" qu’un PPA, ça se discute. Si ce sont les deux seuls choix possibles, je préfère systématiquement le PPA.
Pourquoi ? (j'aurai dit l'inverse .. )
J'aurai pensé que pour la stabilité d'un système, le snap embarquant, si j'ai à peu près compris, toutes (ou quasi (?)) ses bibliothèques et fonctionnant en containeur (?) aurait peu d'interactions avec le système (hôte) et donc moins de chances de le perturber ...
genre, là, je me disais que le snap aurait embarqué (?) sa lib Python2 et l'aurais géré, et... j'en sais rien ... d'où moins pire (?) qu'un dépot qui va utiliser les biblis etc du système et, par ex. continuer à exiger du python2 à un système qui ne le gère plus ... enfin, grosso-modo . C'est où que j'ai faux ?
Dernière modification par vv222 (19-01-2024 14:39:09)
En ligne
vv222 a écrit :Un snap "mieux" qu’un PPA, ça se discute. Si ce sont les deux seuls choix possibles, je préfère systématiquement le PPA.
Pourquoi ? (j'aurai dit l'inverse .. )
Tout simplement parce que ça repose sur un système de paquets que j’utilise déjà, alors qu’en passant par un snap je me retrouve à confier la maintenance de mon système à plusieurs gestionnaires de paquets. Chacun de ces gestionnaires étant incapable de communiquer avec l’autre, je m’attends à ce que ça pose rapidement des soucis.
genre, là, je me disais que le snap aurait embarqué (?) sa lib Python2 et l'aurais géré, et... j'en sais rien ... d'où moins pire (?) qu'un dépot qui va utiliser les biblis etc du système et, par ex. continuer à exiger du python2 à un système qui ne le gère plus ... enfin, grosso-modo .
Dans les deux cas tu te retrouves à utiliser Python 2, peu importe la manière dont il a été fourni. Dans les deux cas c’est une version de Python qui n’est plus maintenue et peut donc entre autres poser des problèmes de sécurité. Si on passe par un PPA, au moment où Python 2 est retiré des dépôts de Debian on a un signal fort que le logiciel reposant dessus devrait être remplacé. Si on passe par un snap, j’ai l’impression qu’on va facilement conserver et utiliser régulièrement des bibliothèques périmées sans se poser de question à leur sujet.
Hors ligne
ça repose sur un système de paquets que j’utilise déjà
oui, mais cela est valable pour toi qui connait bien (et même très bien je présume) le gestionnaire de paquets et la conception/création d'un paquet, est-ce pertinent pour tout le monde ?
Chacun de ces gestionnaires étant incapable de communiquer avec l’autre
(là se dévoile encore mon ignorance ..) euh, ils communiquent entre eux ? Ils en ont besoin ? (à quel point?) je pensai que le snap, dans son bac à sable, n'interagissait surtout qu'avec le noyau .
Dans les deux cas c’est une version de Python qui n’est plus maintenue et peut donc entre autres poser des problèmes de sécurité
eh oui ....
par un snap, j’ai l’impression qu’on va facilement conserver et utiliser régulièrement des bibliothèques périmées
beh oui, du coup ... mais, on dirait qu'avec un ppa aussi (que le signal n'est pas assez fort )
un PPA, au moment où Python 2 est retiré des dépôts de Debian on a un signal fort que le logiciel reposant dessus devrait être remplacé.
alors, pour finir, la question par laquelle il aurait peut-être fallu commencer,
Pourquoi ne pas utiliser de PPA sous Debian ?
En ligne
Pourquoi ne pas utiliser de PPA sous Debian ?
Cette question-ci est beaucoup plus facile
Tout simplement parce que les PPA sont (généralement) conçus uniquement pour Ubuntu, et donc s’attendent à des versions différentes de bibliothèques disponibles sur le système. Si un PPA permet de choisir une branche de Debian plutôt que d’Ubuntu, je ne vois aucune raison de l’éviter si on a besoin du logiciel fourni.
Après le risque est de cumuler les dépôts tiers sans bonne raison, juste pour avoir une version plus récente de pleins de logiciels sans se poser la question du besoin de ces versions récentes. Petit à petit on s’éloigne des versions fournies par Debian, on se retrouve donc avec un système atypique dont le comportement est de plus en plus éloignées d’une Debian "classique".
À mon avis le problème n’est pas tant l’utilisation de PPA sur Debian, mais l’abus de ceux-ci. Ça et le manque de PPA ciblant Debian plutôt que (ou en plus de) Ubuntu.
Hors ligne
> Débuter sur Debian
Principales commandes Linux+ISOs DF+Les cahiers du débutant
> Débuter sur openSUSE
Site officiel + Wiki fr + Forum fr +Guide du débutant sur Leap 15.x
Hors ligne
One thing to keep in mind about using PPAs is that when you add a PPA to your Software Sources, you're giving Administrative access (root) to everyone that can upload to that PPA. Packages in PPAs have access to your entire system as they get installed (just like a regular package from the main Ubuntu Archive), so always decide if you trust a PPA before you add it to your system.
et celle là ?
Keep in mind that anyone can create a PPA, even you. Just because a person signs the Code of Conduct doesn't mean they know what they're doing.
https://askubuntu.com/questions/4983/wh … /4990#4990
Dernière modification par ubub (19-01-2024 22:46:57)
En ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
Hors ligne
Hors ligne
Un soft fourni en snap ou flatpak ne nécessite pas les droits root pour installation donc ne pourra rien faire de "nuisible" à ce moment.
Un snap ou flatpak a de toutes façons accès à ce qui est vraiment sensible : non pas la configuration du système, mais les données de l’utilisateur.
Hors ligne
> Débuter sur Debian
Principales commandes Linux+ISOs DF+Les cahiers du débutant
> Débuter sur openSUSE
Site officiel + Wiki fr + Forum fr +Guide du débutant sur Leap 15.x
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
mais c'est vraiment plus compliqué de créer une version .deb d'une application que de faire seulement un flatpak ?
Comme je ne fais pas de deb ni de flatpak, je ne peux pas répondre en pro mais il est certainement plus aisé de faire UN flatpak que de construire DES paquets pour Debian, Fedora, openSuse, Arch...
De plus, il faut distribuer ces paquets donc les intégrer aux dépôts des distributions alors que pour un flatpack il suffit de le mettre sur flathub.
Quelqu'un qui a réussi à faire un PPA, avec un compte officiel, qui a fait le taf d'intégration de son application pour la distro cible, m'inspire également plus confiance qu'un snapeur / flatpackeur…
Pourquoi ?
Parce que il « a fait le taf d'intégration de son application pour la distro cible » ?
C'est-à-dire ? Il a pris en compte toutes les interactions avec toutes les autres applications/paquets du système (les dépendances & co) ?
[ J'imagine que ça doit rajouter un niveau de complexitude ...
Mais pourtant, c'est bien cela qui fait la notoriété de ces magasins ... Le fait de ne pas s'enquiquiner de la distro cible ...]
Mais, j'aurai pensé que Ubuntu pour SNAP ou Red Hat (? me semble-t-il) pour Flatpack auraient eu un œil disons "paternaliste" dessus pour veiller à ce qu'il n'y ait pas n'importe quoi dedans ..?..
Alors, que si j'ai un peu compris, tout le monde est libre de faire à peu près ce qu'il veut dans sa P Personal Archive, même si ça merdoie (?)
Dernière modification par ubub (21-01-2024 19:00:47)
En ligne
Hors ligne
Je me doute que ça demande du boulot supplémentaire mais c'est vraiment plus compliqué de créer une version .deb d'une application que de faire seulement un flatpak ?
C’est amusant que tu poses la question sous cette forme, pour moi qui suis développeur et mainteneur de paquets c’est la question inverse qui se pose : à quel point distribuer un flatpak ajouterait de la complexité, comparé à ne proposer qu’un .deb ?
---
il est certainement plus aisé de faire UN flatpak que de construire DES paquets pour Debian, Fedora, openSuse, Arch...
La comparaison ne tient pas : quand tu distribues un flatpak (le format de paquet) tu ne fournis ton logiciel qu’aux utilisateurs de flatpak (le gestionnaire de paquets), de la même manière qu’un .deb ne servira qu’aux utilisateurs de dpkg/apt.
Un flatpak ne remplace pas tous les autres paquets. C’est un format qui, comme les autres, ne s’adresse qu’aux utilisateurs d’un gestionnaire de paquets donné.
---
Mais, j'aurai pensé que Ubuntu pour SNAP ou Red Hat (? me semble-t-il) pour Flatpack auraient eu un œil disons "paternaliste" dessus pour veiller à ce qu'il n'y ait pas n'importe quoi dedans ..?..
Aucune idée pour snap, mais pour flatpak n’importe qui peut distribuer n’importe quoi. Red Hat ne contrôle absolument rien de ce côté.
Hors ligne
Un flatpak ne remplace pas tous les autres paquets. C’est un format qui, comme les autres, ne s’adresse qu’aux utilisateurs d’un gestionnaire de paquets donné.
Un paquet utilisable sous toutes les distributions (je n'en connaîs pas qui empêchent flatpak) sans avoir à gérer les dépendances me semble plus simple à faire qu'un paquet par distribution en devant gérer les dépendances pour chaque.
Je préfère éviter ça mais comprends bien celui qui s'en sert.
Hors ligne
Le coup de « Flatpak est utilisable partout, pas comme les autres formats » est un mensonge...
Dans la pratique, flatpak est utilisable sur les systèmes où le gestionnaire de paquets flatpak est installé
C'est certainement vrai, je n'ai simplement jamais vu une distribution Linux majeure ne pas "offrir" ce gestionnaire .
De toute manière on est bien d'accord. Rester sur les paquets diffusés par la distribution est largement préférable à tout ces ajouts.
C'est certainement vrai, je n'ai simplement jamais vu une distribution Linux majeure ne pas "offrir" ce gestionnaire .
Le truc c’est que ce raisonnement peut s’appliquer pour plein d’autres gestionnaires de paquets. Je ne connais par exemple aucune distribution Linux qui ne permette pas d’installer dpkg ou rpm.
Pour autant on ne voit personne dire qu’il ne faudrait plus distribuer que des .deb (ou des .rpm), qu’après tout on peut installer partout. Il n’y a que les promoteurs de flatpak que j’ai pu voir faire preuve de ce genre d’arrogance. Étonnamment même les promoteurs de snap semblent avoir évité ce travers.
Hors ligne
Étonnamment même les promoteurs de snap semblent avoir évité ce travers.
À moins que ce ne soit toi qui ait réussi à éviter les promoteurs de snap.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Debian sid
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot
Hors ligne