Il est vraiment très simple de faire un paquet Debian de base, certes pas conforme 100% à la qualité Debian, mais qui marche. En gros, un tar avec les fichiers, un tar de contrôle et hop, les deux dans un ar. C'est tout. C'est bien plus simple qu'on ne le croit avant d'en faire un.
PS : évidement pour les cas simples, soit 99% des paquets. Si vous voulez du debconf avec paramétrages… C'est un peu plus complexe.
Mais dans la pratique, ce n'est pas aux développeurs de faire eux-mêmes leurs paquets pour chaque distro, si ?
(je précise avant qu'on me pose la question : je suis plutôt fan de Flatpak et sceptique vis-à-vis de ses détracteurs, mais j'ai voulu relayer ce point de vue qui m'avait l'air technologiquement mieux motivé… à l'aune de mes maigres connaissances en la matière. Je vous prie ainsi de croire à la sincérité de ma question ci-dessus.)
Posté par Misc (site web personnel) .
Évalué à 7.
Dernière modification le 23 novembre 2021 à 19:31.
Mais dans la pratique, ce n'est pas aux développeurs de faire eux-mêmes leurs paquets pour chaque distro, si ?
Non. Y en a qui le font, mais c'est une minorité et en général, c'est 2 boulots séparés, parce que ça prends du temps. Parfois, tu as la même organisation qui fait le logiciel et le paquet (éditeur logiciel, logiciel propre à une distribution), mais c'est tout.
Un point du débat que je pige pas, c'est qu'on rajoute une dichotomie la ou il n'y a pas lieu d'en avoir une.
Personne ne force à utiliser des flatpaks, tout comme personne ne force à utiliser des rpms, sauf si personne ne fait le boulot.
Mais si personne ne fait le boulot pour avoir le logiciel dans le format qu'on veut, c'est pas la faute des gens qui font le travail qu'on veut pas. C'est la faute des gens qui ne font rien.
Surtout pour moi le principal problème dans le débat aussi c'est qu'en fait : aucune solution n'est parfaite par conception.
On ne peut pas avoir X distro différentes, avec leur tambouille interne, avec des projets qui ne collaborent pas spécialement pour garantir une compatibilité ascendante parfaite (contrairement à ce qui est dit dans l'article : ces problèmes existent toujours en nombre) avec des dépôts qui permettent de mettre à jour une bibliothèque une fois tout en permettant d'installer la version qu'on veut de chaque application car on veut facilement installer le dernier Firefox même s'il est pas dispo dans ma distro.
Flatpak, Snap et autres répondent à des besoins et sont complémentaires des dépôts. L'un n'est pas meilleur qu'un autre, ça dépend du contexte, et surtout aucune solution ne permet de répondre convenablement à tous les envies. Et on pourra faire les efforts qu'on veut, la flexibilité de Flatpak et Snap (au détriment des ressources par exemple) ne pourra jamais être atteinte par les dépôts. Mais l'efficience des dépôts ne sera jamais atteint pas Snap et Flatpak par essence non plus.
Posté par ff9097 .
Évalué à 2.
Dernière modification le 23 novembre 2021 à 22:27.
Je pense qu'en effet certaines distros iront vers une généralisation du flatpak sur ce qui est graphique. Et d'autres resteront sur le modèle actuel. Au moins ça donnera de vrais différences entre chacunes et ça simplifiera le choix parce qu'aujourd'hui pas mal de distribs sont un peu toutes les mêmes.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
Debian ?
Ubuntu ?
Linux Mint ?
..?
RPM:
RedHat ?
CentOS ?
Fedora ?
..?
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Oui, et c'est complexe, ils maitrisent aussi globalement toute la chaine et peuvent contraindre les employés à cela. Bon courage pour forcer Linux, glibc, systemd, Firefox, GTK, KDE, Qt, etc de suivre la même politique à ce sujet.
D'ailleurs parfois la compatibilité casse un peu (mais bon, pas le choix), et ils tentent de s'extirper de Win32 mais migrer cet écosystème ne se fera pas en une journée et pas mal de développeurs sont contre (parfois pour de bonnes raisons, l'API de remplacement reste limité).
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
C'est ce que veut faire Fedora Silverblue aussi. J'ai fait des articles à ce sujet. ;)
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
Tu as oublié les versions aussi. Uniquement la Debian stable, la oldstable ? RHEL 7, 8 ? Sans compter les tests avec les différentes configuration matériel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 24 novembre 2021 à 11:55.
Sans compter les tests avec les différentes configuration matériel.
Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.
Uniquement la Debian stable, la oldstable ? RHEL 7, 8 ?
Je trouve pas ça très loyale. Oldstable ne fait que des mises à jours de sécurité. Je n'ai jamais vu de packaging snap/appimage/flatpack faire autre chose que des mise à jour de leur versions (et pas de leurs dépendances par exemple). Ça correspond donc à suivre la version principale (stable ou LTS selon les distributions ou les volontés des mainteneurs) des distributions.
Il y a toute une partie de la simplicité de ses packagings qui ne vient pas du fait qu'ils ont corrigé des difficultés, mais qu'ils ne sont tout simplement pas adressé.
Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.
Non, mais le runtime est le même sur les distributions. Tu ne dois pas faire le test avec n matériel x m distributions.
Je trouve pas ça très loyale. Oldstable ne fait que des mises à jours de sécurité. Je n'ai jamais vu de packaging snap/appimage/flatpack faire autre chose que des mise à jour de leur versions (et pas de leurs dépendances par exemple). Ça correspond donc à suivre la version principale (stable ou LTS selon les distributions ou les volontés des mainteneurs) des distributions.
Oui, mais si tu dois faire un paquets sur oldstable et sur stable, tu dois bien testé deux fois. Je ne vois pas ce que tu veux dire avec ces mises à jour de sécurité. Ou alors, tu veux dire que tu ne mets plus à jour sur oldstable, mais ça ne correspond pas à ce qui est fait lorsqu'un logiciel est distribué par les développeurs et pas par les distributions.
Il y a toute une partie de la simplicité de ses packagings qui ne vient pas du fait qu'ils ont corrigé des difficultés, mais qu'ils ne sont tout simplement pas adressé.
Je ne vois pas de quelles difficultés tu parles dans le contexte de mon post.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.
Non, mais le runtime est le même sur les distributions. Tu ne dois pas faire le test avec n matériel x m distributions.
Ce n matériel existe aussi sur flatpack, snap et appimage.
Oui, mais si tu dois faire un paquets sur oldstable et sur stable, tu dois bien testé deux fois. Je ne vois pas ce que tu veux dire avec ces mises à jour de sécurité. Ou alors, tu veux dire que tu ne mets plus à jour sur oldstable, mais ça ne correspond pas à ce qui est fait lorsqu'un logiciel est distribué par les développeurs et pas par les distributions.
Oldstable ne subit que des mises à jour de sécurité pendant un an donc si ça correspond à ce qui est fait par les distributions (du moins Debian, je ne connais pas d'autre oldstable). Être plus royaliste que le roi pour trouver des arguments c'est dommage.
Je ne vois pas de quelles difficultés tu parles dans le contexte de mon post.
Les snap, flatpack et appimage ne sont pas utilisé pour faire des mises à jour de sécurité. Pour les utiliser, je n'ai jamais eu de mise à jour pour mettre à jour une bibliothèque qu'ils tirent. La seule mise à jour de sécurité qu'il y a c'est les runtimes pour flatpack, mais tout n'est pas dans le runtime.
Les distributions cherchent à minimiser le temps que tu passe à utiliser une bibliothèque ayant un problème de sécurité, ces packagings ne sont pas utilisés pour ça (ils pourraient en principe mais je ne les ai pas vu le faire) et de l'autre coté tu parle de oldstable qui ne reçoit que des mises à jour de sécurité. snap, flatpack et appimage ne sont pas prévu pour.
Ce n matériel existe aussi sur flatpack, snap et appimage.
Mais tu ne dois faire le test qu'une fois par matériel.
Oldstable ne subit que des mises à jour de sécurité pendant un an donc si ça correspond à ce qui est fait par les distributions (du moins Debian, je ne connais pas d'autre oldstable). Être plus royaliste que le roi pour trouver des arguments c'est dommage.
Ce n matériel existe aussi sur flatpack, snap et appimage.
Mais tu ne dois faire le test qu'une fois par matériel.
C'est ce que je dis depuis le début. Tu souligne que le matériel qui est la même problématique des 2 côtés et qui est beaucoup plus chiant que les distributions, mais par chance quelque soit le système de paquet tout le monde s'en fout et fais 1 à 3 binaires et ne fais pas forcément de batterie de test complet sur chacun.
Euh, je n'invente pas un truc, beaucoup de monde qui fournit des paquets, les fournissent pour plusieurs versions des distributions
Ils sont plus royaliste que le roi, oui tenter de faire plus et mieux que les distributions c'est douloureux. C'est bien pour ça que les distributions sont en peine pour le faire.
C'est ce que je dis depuis le début. Tu souligne que le matériel qui est la même problématique des 2 côtés et qui est beaucoup plus chiant que les distributions
Non, je dis que le matériel est à testé sur chaque distribution (vu que chaque distribution a sa version des drivers). Donc si tu as 3 matos et 3 distributions, ça fait 9 tests à faire.
Ils sont plus royaliste que le roi, oui tenter de faire plus et mieux que les distributions c'est douloureux. C'est bien pour ça que les distributions sont en peine pour le faire.
Dites moi ce dont vous avez besoin, je vous dirais comment vous en passé. C'est un peu une demande récurrente, surtout pour les version précédentes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Dites moi ce dont vous avez besoin, je vous dirais comment vous en passé. C'est un peu une demande récurrente, surtout pour les version précédentes.
Ce n'est pas ce que je dis. Que tu sois packagers pour une distribution ou pour un logiciel, que ce soit avec deb, rpm, flatpack, appimage, un sh, ou ce que tu veux, les gens ne sont pas là pour t'embêter. Avoir tout qui marche sur tout matériel supportant à la fois des versions de 20 ans age et les toutes dernières releases n'est pas triviale. Les distributions représente un compromis à ça. Tenter de faire autrement c'est nager à contre courant. Tu peux vouloir le faire, mais ça va être douloureux.
Appimage et autres représentent d'autres compromis : ceux sont des distributions au même titre que debian ou redhat.
Posté par claudex .
Évalué à 3.
Dernière modification le 24 novembre 2021 à 14:46.
Je ne sais pas comment tu as testé, mais j'ai déjà remarqué que les tests sur la machine où j'avais développé le flatpak n'était pas représentatifs, parce qu'on fait pas mal de truc à la main (mais c'est aussi le cas avec les paquets deb).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Il y a les deux points de vue… que j'analyserai ainsi :
Si tu fais un logiciel fermé, tu dois distribuer les paquets toi-même (toute façon y a pas de valeur ajouter pour la distribution de juste empaqueter des binaires sans pouvoir contrôler…) Dans ce cas de figure, il va de soi que tu ne peux pas couvrir tous les cas possibles (tu vas par exemple faire les paquets pour mon FreeBSD ou mon Amiga ou le Haiku à côté ?) et évidement la pleurniche qui revient souvent est qu'il y a trop de formats à supporter ; et pour résoudre cela on en créé un autre format https://xkcd.com/927/
Si tu fais un logiciel dont le code est ouvert, alors il te faut juste indiquer clairement les prérequis de ton environnement de construction. Ce sera aux mainteneurs et mainteneuses des distributions de faire les paquets… Cela permet de garantir la cohérence de la distribution (aussi bien au niveau des emplacements des fichiers que de la gestion des dépendances et diverses considérations de sécurité dont les devs n'ont souvent pas conscience.) Dans ce cas ci, le logiciel sera distribué sur BeOS ou Plan9 pourvu qu'il y ait une personne (ou plusieurs) qui joue(nt) le rôle de maintainer pour la distribution.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Chez Haiku (puisqu'on parle de nous, hein…), on aimerait bien que les développeurs d'applications distribuent eux-même leur travail et qu'on aie pas besoin de tout packager nous-mêmes.
Notre approche est la suivante:
- Une "distribution" standard du système, qui est la seule à avoir le droit d'utiliser la marque Haiku sans autres précision (d'autres distributions ont existé, par exemple Senryu, TiltOS, ou Discover Haiku)
- Une ABI et API stable. Actuellement c'est celle de BeOS, qui n'a pas bougé depuis 20 ans. Mais on est conscients que ce n'est pas réaliste car ça imposerait de tout compiler avec gcc2 et de n'utiliser aucune des nouvelles APIs ajoutées depuis,
- L'introduction de nouvelles APIs se fait d'abord dans des bibliothèques statiques etdans un namespace dédié. Les applications utilisant ces APIs embarquent donc une copie du code concerné, etne sont pas affectées par les mises à jour
- Pour les APIs stables utilisables en bibliothèques partagées, diverses astuces pour se garder des moyens de faire évoluer les choses: réservation d'espace dans la vtable et les champ de tous les objets C++, surcharge systématique de certaines méthodes pour pouvoir en modifier le comportement plus tard, versionning de symboles, ajout de bouchons permettant aux applications utilisant une fonction qui n'existe plus de continuer à fonctionner, etc.
- Fourniture d'une API qui couvre pas mal de besoins (graphique, réseau, multimédia, …) évitant ainsi la prolifération de bibliothèque faisant toutes un peu la même chose
Ça marche plutôt bien pour les applications natives. C'est plus compliqué pour les applications portées depuis Linux ou il y a souvent plein de dépendances vers diverses bibliothèques et des problèmes de compatibilité qui surviennent très régulièrement. Pas trop d'accord avec l'auteur de l'article pour dire que c'est définitivement réglé, donc…
Je ne parlais pas de l'équipe core mais un niveau intermédiaire entre le système et les devs et c'est normalement ça les maintainers:-) Ces dernier savent justement comment ça marche et les API et comment faire les choses proprement, alors que si tu demandes aux devs qui n'utilisent probablement pas le système ça va être le boxon. Mais bon, ces devs qui veulent garder tout le contrôle (ou pour des systèmes où il n'y a pas de personne/équipe dédiée à l'empaquetage), il y a flatpack et snap (et ce n'est pas définitivement réglé)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
On a pas le luxe chez Haiku d'être assez nombreux pour clairement séparer les deux. En théorie c'est le cas, les paquets pour les logiciels tiers sont gérés par Haikuports.
En pratique, les gens qui essaient de porter des logiciels trouvent des bugs dans le système et souvent finissent par les corriger eux-même. Et les gens qui développent l'OS veulent utiliser des logiciels ou bibliothèques qui ne sont pas encore packagées (ou pas dans la bonne version) et doivent le faire eux-même. Il y a donc une assez large intersection entre les deux équipes, et une seule association (Haiku inc) qui paie les serveurs et autres dépenses pour les deux projets.
Pour les applications natives, il n'y a pas vraiment besoin de passer par un "maintainer". Les développeurs d'applications sont aussi des utilisateurs de l'OS (ou même des développeurs de l'OS) et connaissent assez bien le système. Ce n'est pas très compliqué de distribuer un logiciel, soit sous forme d'un paquet hpkg, soit sous forme d'un simple fichier zip à décompresser.
Pour les applications portées, ça dépend, on a certains développeurs qui sont motivés pour faire les choses proprement, d'autres qui n'ont pas du tout envie de gérer des cas particuliers, et un peu de tout entre les deux.
Mais surtout, ce qui est important: on compte sur les utilisateurs pour se plaindre quand un logiciel est plus gros que l'installation de base de Haiku (quelques centaines de Mo).
On compare un système très mature comme le système de paquets mais où aucun format ni gestionnaire de paquets s'est imposé. On se retrouve donc aujourd'hui avec plusieurs formats qui sont tous un peu les mêmes en différents et pareil pour les gestionnaire de paquets. On est tous habitué au deb/rpm et apt/yum/… et ça continue par inertie.
Et de l'autre on a un système quasi-unique (je compte pas snap qui n'est poussé et n'est pris en charge que sur ubuntu) qui est encore très récent et dont pas mal de défauts mentionnés sont des choix qui peuvent être remis en cause facilement comme l'attribution de certaines permissions par défaut où le but était de ne pas trop changer les habitudes des utilisateurs.
Sur la sécurité c'est risible, actuellement c'est open-bar. Les applications ont tout les droits sur $HOME et même l'accés en lecture à /. Avec flatpak je retire les droits sans soucis si j'ai envie et sans bidouilles.
Snap + AppImage + Flatpak, c'est pas vraiment quasi-unique. Surtout que ça ne remplace pas les autres solutions, ça ne fait qu'en rajouter encore plus.
des mises à jour fréquentes et obligatoires pour les jeux en ligne ;
le besoin d'un accès "direct mais pas trop" aux piles graphiques, audio et inputs.
Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?
Ce qui s'en rapproche le plus aujourd'hui:
le brouteur avec les API canvas/webgl/webaudio/gamepad : la sécurité est bonne, mais il est difficile de jouer hors ligne ou même de faire des jeux avec des gigots de ressources, les perfs ne sont pas au top ;
libretro : le hors ligne et les gros jeux sont possibles, les perfs sont top, mais il n'y a aucune sécurité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
On pourrait distribuer chaque jeu sur un support de stockage bootable contentant tout le code nécessaire, permettant à l'éditeur du jeu de choisir exactement ce qu'il inclut et de ne pas avoir de conflit entre les jeux.
Et on appellerait ça une console de jeux? ça serait simple et facile à utiliser.
Je ne vois pas très bien de quoi tu parles, je possède une "console de jeux" à la maison, et non seulement les jeux ne sont pas tous sur un support dédié, mais en plus je dois régulièrement mettre à jour le système pour pouvoir lancer ces jeux, et le plus souvent ça prend des plombes. Tu es sûr qu'avoir "tout le code nécessaire" fait mieux fonctionner les choses ?
(le saviez-vous ? Windows CE n'était pas installé sur les Dreamcast, malgré la présence du logo sur la console. C'étaient les disques de jeu eux-même qui incluaient WinCE. La plupart ne s'en servaient pas de toute façon)
La NES et la SuperNES aussi, et la MegaDrive chez Sega. Je pense que la Nintendo 64 aussi mais je me trompe peut-être.
Pour la Game Boy et l'Atari Lynx il y a un BIOS de quelques centaines d'octets et qui ne peut pas être appelé par les jeux (il est là juste pour vérifier que la cartouche insérée est valide, et démarrer l'exécution du code).
Pour les consoles sans cartouches c'est effectivement plus compliqué.
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
Mais même une console qui aurait un noyau Linux et laisserait chaque jeu démarrer son propre userspace, ça marcherait peut être pas si mal que ça, et ça ressemblerait finalement assez aux Snap et Flatpak, en moins compliqué. Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
C'est que font les brouteurs web :-)
Mais c'est assez bloated. Il faudrait un brouteur jeu !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…
Tu oublies aussi la partie où les constructeurs vérifient chaque jeu un par un et leur font passer des semaines voire des mois en QA avant d'accepter leur commercialisation. Ça a été un sacré frein lorsque les premiers magasins dématérialisés ont commencé à ouvrir leurs portes aux devs indés, à la septième génération de consoles. Même aujourd'hui je doute que ce soit une promenade de santé pour les petits créateurs (parce que bien entendu, les gros n'en ont apparemment pas à s'en soucier, n'est-ce pas CD Projekt). Mine de rien, si on veut vraiment un ordinateur qui se comporte comme une console de jeux, ça existe déjà ; ça s'appelle l'iPad.
Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Je pense que dans de très fréquents cas (notamment en dev web), les développeurs n'envisagent pas ce que signifie pour les hébergeurs de maintenir 10 ans leur application à jour.
La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio Que :
$ apt install moment-js
$ yum install python-trio
[…] j'ai plus confiance dans NPM/PyPI/[…] pour empaqueter correctement une lib […]
Je suis le mainteneur de quelques paquets sur NPM et PyPI, et je ne vois pas ce qui aurait pu m'empêcher d'y mettre n'importe quoi. Du coup, il me semble bien que faire confiance à un paquet sur NPM/PyPI revient à faire confiance au quidam qui l'a empaqueter.
Pour ma part, les paquets que j'ai mis sur NPM/PyPI ne dépendent d'aucun autre paquet dont je ne suis pas le mainteneur. C'est d'ailleurs un argument de « vente » de mes bibliothèques, cependant plus pour des considérations de légèreté que de sécurité.
Tiens, je viens de voir qu'il y a maintenant un bouton Report malware dans NPM…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.
Je ne compte plus le nombre de fois ou j'ai eu des soucis avec un apt install python-prout qui s'est terminé par un virtualenv dans /opt.
La confiance dont tu parles concerne la sécurité, et oui un dépôt officiel d'une distribution ou chaque contribution est revue par un organisme tier a plus de crédibilité qu'un dépôt communautaire (coucou AUR et archlinux?).
Maintenant, si dans ta société tu as les moyens pour une équipe en charge de la cybersécurité, ces derniers vont te fournir :
un dépôt DEB/RPM/whatever contenant une liste de logiciel autorisé à installer
un dépôt Maven/NPM/PyPI privé contenant les librairies qui ont été auditées et autorisées
Si tu veux être parano et ne pas faire confiance a un quidam, tu l'es jusqu'au bout et tu ne fais pas confiance à un organisme tier sur lequel tu n'as aucun contrôle. En fait tu va vraiment jusqu'au bout et tu fais pas confiance à quelque chose qui a été produit par un humain.
La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.
Sur cet aspect, c'est possible que ce soit effectivement mieux géré. Cependant, pour des paquets qui embarquent du code natif, je me demande si passer par le gestionnaire de paquets de l'OS n'apporte pas certains avantages, sachant qu'on ne peut pas embarquer l'ensemble des codes natifs propres à chaque système d'exploitation et/ou architecture matériel ciblé avec les paquets NPM/PyPI qui l'utilisent.
J'ai fait des paquets NPM qui installent du code natif, et ce n'est pas simple. De mémoire, soit le code compilé pour la plateforme cible est disponible quelque part sur internet, et il le récupère, soit il lance une compilation, mais sans se préoccuper de la présence du compilateur adéquat.
Pour PyPI, je n'ai pas encore fait, mais c'est en projet, sachant qu'il existe des paquets sur PyPI qui le font et dont je compte bien m'inspirer. C'est peut-être plus facile, sachant que si Python est si populaire, c'est en grande partie grâce aux nombreuses bibliothèques tierces qui sont disponibles pour ce langage et dont les plus populaires s'appuient, pour beaucoup, sur du code natif…
Ceci dit, je n'ai jamais crée de paquets pour une quelconque distribution Linux, donc je ne peux pas m'avancer sur les avantages/inconvénients de cette méthode par rapport à l'utilisation de NPM/PyPI…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
gcc
g++
rustc (pour le paquet cryptography, donc tout ce qui touche de prêt ou de loin à SSL ou la génération de nombre aléatoire)
myriade de libprout-dev
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans C:\Program Files/opt. C'est juste plus simple.
Cependant, pour des paquets qui embarquent du code natif
Oof, tu piques la où ça fait mal ! C'est pas très fair play :p
J'essayais juste de trouver pour quelle raison on pouvait préférer le gestionnaire de paquets de l'OS plutôt que le dédié :-).
Je viens juste de comprendre le fonctionnement des wheels. En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
Concrètement, on a une section, dans le package.json, qui ressemble à ça :
Ça permet à NPM de construire l'URL où récupérer le code natif pour la plateforme ciblée (noter le {platform}-{arch} pour l'entrée package_name, dont on trouve l'équivalent dans le nommage des wheels de PyPI), à charge pour l'empaqueteur d'y placer le fichier adéquat.
En fait, c'est node-[pre-]gyp qui s'occupe de la récupération, et on peut lui indiquer de lancer la compilation s'il ne trouve pas le fichier attendu. Ce qui, le cas échéant, ne peut évidemment fonctionner que si le compilateur adéquat et présent…
Ceci dit écrit, même si les binaires sont disponibles sur PyPI à travers les wheels, c'est quand même à l'empaqueteur de les générer, ou bien ?
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans C:\Program Files/opt. C'est juste plus simple.
Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
Good to know :)
c'est quand même à l'empaqueteur de les générer, ou bien ?
T'as de l'outillage pour t'aider à les générer, mais sur le principe oui, si l'empaqueteur ne les fournis pas, personne va les fournir pour toi.
Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?
Tu as par exemple des images Docker pour te fournir une alpine/debian/ubuntu avec un JDK dans une version spécifique. Pareil pour Python, Erlang/Elixir, etc…
Fun fact, j'ai une application Elixir qui embarque dans son image Docker un binaire Go, dans la phase de build j'ai ceci:
COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
ENV PATH="/usr/local/go/bin:${PATH}"
Alors certes, j'imagine mal une image Docker "python-django" ou "node-expressjs" sur DockerHub. Cependant j'ai pas mal vu en entreprise des images Docker de base du style "java-jdk11-springboot" partagées entre les différentes teams.
Accessoirement, pour Windows si tu veux bosser avec la SDL, tu chope un ZIP qui te donne les headers et les DLLs.
Avant d'installer un paquet de AUR on conseille fortement :
* de lire les commentaires
* de lire le fichier PKGBUILD qui te montre exactement ce qui sera téléchargé et où ça va être installé.
C'est écrit en gros, partout. En général on est en mesure de s'assurer que la source est bien "officielle" (le dépôt Github du développeur par ex.) M'enfin oui ce n'est pas comparable avec des paquets revus par les mainteneurs d'une distro. Cela dit c'est pas la même chose avec les PPA de Ubuntu ? (vraie question, je n'ai pas utilisé depuis longtemps)
C'est le même problème avec tout les dépôts communautaires sans review.
Avant d'installer un paquet de AUR on conseille fortement :
Les teams DevSecOps me chuchotent à l'oreille que ces conseils s'appliquent à toutes les dépendances externes peu importe leurs provenance (dépôt officiel ou non).
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.
La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.
La maintenance à long terme demande:
d'avoir des libs à jour et qui fonctionnent ;
un seul système de build (et pas un par distrib).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
se mettre d'accord sur un système de paquets commun
Même si toutes les distributions utiliseraient RPM, le problème ne serait pas résolu. Ce serait un progrès mais insuffisant.
Déjà car chaque distribution nomme ses paquets de manière différentes. Si c'est souvent le même, parfois c'est très différent. Pensons à kernel chez Red-Hat pour linux côté Debian. Ou Apache pour Debian, httpd pour Red Hat. Du coup pour les dépendances d'un paquet ça pose problème.
Ensuite les options de compilation et le découpage des paquets (et de fait les dépendances) sont différentes. Certaines distributions peuvent faire un gros paquet Libreoffice qui fournit tout, quand d'autres vont avoir un paquet par logiciel fourni par Libreoffice. L'un est plus simple, l'autre permet d'être plus modulaire (et donc potentiellement n'installer que ce qui est vraiment nécessaire). Il n'y a pas de choix parfaits à ce sujet.
s'assurer d'avoir des API / ABI stables
Cela dépend moins des distributions que de la chaine de compilation et des bibliothèques employées par les logiciels fournis. Ce n'est pas de la faute de Fedora ou Debian si GNOME migre vers GTK4 qui n'est pas compatible avec GTK+3 par exemple.
C'est l'avantage du libre, tu peux composer ce que tu veux selon tes envies et besoin, l'inconvénient c'est qu'il fragmente l'écosystème et rend la tâche plus complexe pour les personnes extérieures. Flatpak est un moyen (comme d'autres) de résoudre ce conflit, mais là encore cette solution a des inconvénients.
À un moment il faut réaliser qu'il n'y a aucune solution technique parfaite, et que d'aller dans un sens a un impact négatif sur d'autres paramètres.
Posté par Renault (site web personnel) .
Évalué à 3.
Dernière modification le 25 novembre 2021 à 14:56.
Elle a ses avantages et ses inconvénients.
Si tu supprimes les paquets pour la faire à la macOS ou Windows, ça va certes améliorer cet aspect significativement, mais ça va râler dans les chaumières.
Notons que par exemple Fedora Silverblue comme d'autres tentent une approche nouvelle, qui n'est pas parfaite mais a son intérêt.
Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
Pour ceux qui l'ignorent, Endless OS est une distribution qui utilise exclusivement les flatpaks pour gérer ses paquets (sur le même principe que Fedora Silverblue si je ne m'abuse). Un des employés d'Endless, Will Thompson, a voulu calculer l'espace disque que ça lui occupait (puisque l'un des reproches faits dans le billet de Ludocode est que Flatpak prend trop de place). Un aperçu :
On peut ne pas être d'accord sur le fait que ces chiffres soient gros ou petits, comparés aux points positifs que Flatpak apporte ou non. Mais les chiffres en eux-même sont disponibles à la consultation, tout comme une bonne partie du travail actuel ou futur pour rendre ces chiffres aussi petits/gros qu'ils le sont. Personnellement, je pense que le compromis m'est nettement favorable, ainsi qu'aux utilisateurs d'Endless OS, d'autant plus que depuis le passage au tout-Flatpak, l'installation immutable de base d'Endless OS ne fait que 4,2 GB.
# Faites des paquets Debian pour vos applications
Posté par Nodeus . Évalué à 2. Dernière modification le 23 novembre 2021 à 17:41.
Et pas que Debian les rpm ça marche aussi.
mais des paquets pour les dépôts des distributions.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Il est vraiment très simple de faire un paquet Debian de base, certes pas conforme 100% à la qualité Debian, mais qui marche. En gros, un tar avec les fichiers, un tar de contrôle et hop, les deux dans un ar. C'est tout. C'est bien plus simple qu'on ne le croit avant d'en faire un.
PS : évidement pour les cas simples, soit 99% des paquets. Si vous voulez du debconf avec paramétrages… C'est un peu plus complexe.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 23 novembre 2021 à 21:44.
Tout aussi simple de faire un paquet CentOS ou Slackware ; mais on n'a effectivement pas toutes les fonctionnalités Avancées de APT…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 23 novembre 2021 à 18:45.
Mais dans la pratique, ce n'est pas aux développeurs de faire eux-mêmes leurs paquets pour chaque distro, si ?
(je précise avant qu'on me pose la question : je suis plutôt fan de Flatpak et sceptique vis-à-vis de ses détracteurs, mais j'ai voulu relayer ce point de vue qui m'avait l'air technologiquement mieux motivé… à l'aune de mes maigres connaissances en la matière. Je vous prie ainsi de croire à la sincérité de ma question ci-dessus.)
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Misc (site web personnel) . Évalué à 7. Dernière modification le 23 novembre 2021 à 19:31.
Non. Y en a qui le font, mais c'est une minorité et en général, c'est 2 boulots séparés, parce que ça prends du temps. Parfois, tu as la même organisation qui fait le logiciel et le paquet (éditeur logiciel, logiciel propre à une distribution), mais c'est tout.
Un point du débat que je pige pas, c'est qu'on rajoute une dichotomie la ou il n'y a pas lieu d'en avoir une.
Personne ne force à utiliser des flatpaks, tout comme personne ne force à utiliser des rpms, sauf si personne ne fait le boulot.
Mais si personne ne fait le boulot pour avoir le logiciel dans le format qu'on veut, c'est pas la faute des gens qui font le travail qu'on veut pas. C'est la faute des gens qui ne font rien.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Renault (site web personnel) . Évalué à 10.
Surtout pour moi le principal problème dans le débat aussi c'est qu'en fait : aucune solution n'est parfaite par conception.
On ne peut pas avoir X distro différentes, avec leur tambouille interne, avec des projets qui ne collaborent pas spécialement pour garantir une compatibilité ascendante parfaite (contrairement à ce qui est dit dans l'article : ces problèmes existent toujours en nombre) avec des dépôts qui permettent de mettre à jour une bibliothèque une fois tout en permettant d'installer la version qu'on veut de chaque application car on veut facilement installer le dernier Firefox même s'il est pas dispo dans ma distro.
Flatpak, Snap et autres répondent à des besoins et sont complémentaires des dépôts. L'un n'est pas meilleur qu'un autre, ça dépend du contexte, et surtout aucune solution ne permet de répondre convenablement à tous les envies. Et on pourra faire les efforts qu'on veut, la flexibilité de Flatpak et Snap (au détriment des ressources par exemple) ne pourra jamais être atteinte par les dépôts. Mais l'efficience des dépôts ne sera jamais atteint pas Snap et Flatpak par essence non plus.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par ff9097 . Évalué à 2. Dernière modification le 23 novembre 2021 à 22:27.
Je pense qu'en effet certaines distros iront vers une généralisation du flatpak sur ce qui est graphique. Et d'autres resteront sur le modèle actuel. Au moins ça donnera de vrais différences entre chacunes et ça simplifiera le choix parce qu'aujourd'hui pas mal de distribs sont un peu toutes les mêmes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Misc (site web personnel) . Évalué à 3.
Bien plus que les gens qui font des choses, oui.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par David Delassus (site web personnel) . Évalué à 3.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
cf Linux Distribution Timeline
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
RPM:
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
https://link-society.com - https://kubirds.com
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Renault (site web personnel) . Évalué à 3.
Oui, et c'est complexe, ils maitrisent aussi globalement toute la chaine et peuvent contraindre les employés à cela. Bon courage pour forcer Linux, glibc, systemd, Firefox, GTK, KDE, Qt, etc de suivre la même politique à ce sujet.
D'ailleurs parfois la compatibilité casse un peu (mais bon, pas le choix), et ils tentent de s'extirper de Win32 mais migrer cet écosystème ne se fera pas en une journée et pas mal de développeurs sont contre (parfois pour de bonnes raisons, l'API de remplacement reste limité).
C'est ce que veut faire Fedora Silverblue aussi. J'ai fait des articles à ce sujet. ;)
[^] # Re: Faites des paquets Debian pour vos applications
Posté par claudex . Évalué à 3.
Tu as oublié les versions aussi. Uniquement la Debian stable, la oldstable ? RHEL 7, 8 ? Sans compter les tests avec les différentes configuration matériel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Faites des paquets Debian pour vos applications
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 24 novembre 2021 à 11:55.
Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.
Je trouve pas ça très loyale. Oldstable ne fait que des mises à jours de sécurité. Je n'ai jamais vu de packaging snap/appimage/flatpack faire autre chose que des mise à jour de leur versions (et pas de leurs dépendances par exemple). Ça correspond donc à suivre la version principale (stable ou LTS selon les distributions ou les volontés des mainteneurs) des distributions.
Il y a toute une partie de la simplicité de ses packagings qui ne vient pas du fait qu'ils ont corrigé des difficultés, mais qu'ils ne sont tout simplement pas adressé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Faites des paquets Debian pour vos applications
Posté par claudex . Évalué à 3.
Non, mais le runtime est le même sur les distributions. Tu ne dois pas faire le test avec n matériel x m distributions.
Oui, mais si tu dois faire un paquets sur oldstable et sur stable, tu dois bien testé deux fois. Je ne vois pas ce que tu veux dire avec ces mises à jour de sécurité. Ou alors, tu veux dire que tu ne mets plus à jour sur oldstable, mais ça ne correspond pas à ce qui est fait lorsqu'un logiciel est distribué par les développeurs et pas par les distributions.
Je ne vois pas de quelles difficultés tu parles dans le contexte de mon post.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Faites des paquets Debian pour vos applications
Posté par barmic 🦦 . Évalué à 2.
Ce n matériel existe aussi sur flatpack, snap et appimage.
Oldstable ne subit que des mises à jour de sécurité pendant un an donc si ça correspond à ce qui est fait par les distributions (du moins Debian, je ne connais pas d'autre oldstable). Être plus royaliste que le roi pour trouver des arguments c'est dommage.
Les snap, flatpack et appimage ne sont pas utilisé pour faire des mises à jour de sécurité. Pour les utiliser, je n'ai jamais eu de mise à jour pour mettre à jour une bibliothèque qu'ils tirent. La seule mise à jour de sécurité qu'il y a c'est les runtimes pour flatpack, mais tout n'est pas dans le runtime.
Les distributions cherchent à minimiser le temps que tu passe à utiliser une bibliothèque ayant un problème de sécurité, ces packagings ne sont pas utilisés pour ça (ils pourraient en principe mais je ne les ai pas vu le faire) et de l'autre coté tu parle de oldstable qui ne reçoit que des mises à jour de sécurité. snap, flatpack et appimage ne sont pas prévu pour.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Faites des paquets Debian pour vos applications
Posté par claudex . Évalué à 3.
Mais tu ne dois faire le test qu'une fois par matériel.
Euh, je n'invente pas un truc, beaucoup de monde qui fournit des paquets, les fournissent pour plusieurs versions des distributions: https://eid.belgium.be/en/linux-eid-software-installation https://support.google.com/chrome/a/answer/7100626?hl=en https://about.gitlab.com/install/ https://docs.microsoft.com/en-us/microsoftteams/hardware-requirements-for-the-teams-app
Pas quand les développeurs de l'application fournissent le deb directement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Faites des paquets Debian pour vos applications
Posté par barmic 🦦 . Évalué à 2.
C'est ce que je dis depuis le début. Tu souligne que le matériel qui est la même problématique des 2 côtés et qui est beaucoup plus chiant que les distributions, mais par chance quelque soit le système de paquet tout le monde s'en fout et fais 1 à 3 binaires et ne fais pas forcément de batterie de test complet sur chacun.
Ils sont plus royaliste que le roi, oui tenter de faire plus et mieux que les distributions c'est douloureux. C'est bien pour ça que les distributions sont en peine pour le faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Faites des paquets Debian pour vos applications
Posté par claudex . Évalué à 3.
Non, je dis que le matériel est à testé sur chaque distribution (vu que chaque distribution a sa version des drivers). Donc si tu as 3 matos et 3 distributions, ça fait 9 tests à faire.
Dites moi ce dont vous avez besoin, je vous dirais comment vous en passé. C'est un peu une demande récurrente, surtout pour les version précédentes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Faites des paquets Debian pour vos applications
Posté par barmic 🦦 . Évalué à 2.
Ce n'est pas ce que je dis. Que tu sois packagers pour une distribution ou pour un logiciel, que ce soit avec deb, rpm, flatpack, appimage, un sh, ou ce que tu veux, les gens ne sont pas là pour t'embêter. Avoir tout qui marche sur tout matériel supportant à la fois des versions de 20 ans age et les toutes dernières releases n'est pas triviale. Les distributions représente un compromis à ça. Tenter de faire autrement c'est nager à contre courant. Tu peux vouloir le faire, mais ça va être douloureux.
Appimage et autres représentent d'autres compromis : ceux sont des distributions au même titre que debian ou redhat.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Faites des paquets Debian pour vos applications
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Faire le test, c'est prendre le risque de se rendre compte que ça bugge :-)
https://linuxfr.org/nodes/118350/comments/1788497
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par claudex . Évalué à 3. Dernière modification le 24 novembre 2021 à 14:46.
Je ne sais pas comment tu as testé, mais j'ai déjà remarqué que les tests sur la machine où j'avais développé le flatpak n'était pas représentatifs, parce qu'on fait pas mal de truc à la main (mais c'est aussi le cas avec les paquets deb).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Il y a les deux points de vue… que j'analyserai ainsi :
Si tu fais un logiciel fermé, tu dois distribuer les paquets toi-même (toute façon y a pas de valeur ajouter pour la distribution de juste empaqueter des binaires sans pouvoir contrôler…) Dans ce cas de figure, il va de soi que tu ne peux pas couvrir tous les cas possibles (tu vas par exemple faire les paquets pour mon FreeBSD ou mon Amiga ou le Haiku à côté ?) et évidement la pleurniche qui revient souvent est qu'il y a trop de formats à supporter ; et pour résoudre cela on en créé un autre format https://xkcd.com/927/
Si tu fais un logiciel dont le code est ouvert, alors il te faut juste indiquer clairement les prérequis de ton environnement de construction. Ce sera aux mainteneurs et mainteneuses des distributions de faire les paquets… Cela permet de garantir la cohérence de la distribution (aussi bien au niveau des emplacements des fichiers que de la gestion des dépendances et diverses considérations de sécurité dont les devs n'ont souvent pas conscience.) Dans ce cas ci, le logiciel sera distribué sur BeOS ou Plan9 pourvu qu'il y ait une personne (ou plusieurs) qui joue(nt) le rôle de maintainer pour la distribution.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Faites des paquets Debian pour vos applications
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Chez Haiku (puisqu'on parle de nous, hein…), on aimerait bien que les développeurs d'applications distribuent eux-même leur travail et qu'on aie pas besoin de tout packager nous-mêmes.
Notre approche est la suivante:
- Une "distribution" standard du système, qui est la seule à avoir le droit d'utiliser la marque Haiku sans autres précision (d'autres distributions ont existé, par exemple Senryu, TiltOS, ou Discover Haiku)
- Une ABI et API stable. Actuellement c'est celle de BeOS, qui n'a pas bougé depuis 20 ans. Mais on est conscients que ce n'est pas réaliste car ça imposerait de tout compiler avec gcc2 et de n'utiliser aucune des nouvelles APIs ajoutées depuis,
- L'introduction de nouvelles APIs se fait d'abord dans des bibliothèques statiques etdans un namespace dédié. Les applications utilisant ces APIs embarquent donc une copie du code concerné, etne sont pas affectées par les mises à jour
- Pour les APIs stables utilisables en bibliothèques partagées, diverses astuces pour se garder des moyens de faire évoluer les choses: réservation d'espace dans la vtable et les champ de tous les objets C++, surcharge systématique de certaines méthodes pour pouvoir en modifier le comportement plus tard, versionning de symboles, ajout de bouchons permettant aux applications utilisant une fonction qui n'existe plus de continuer à fonctionner, etc.
- Fourniture d'une API qui couvre pas mal de besoins (graphique, réseau, multimédia, …) évitant ainsi la prolifération de bibliothèque faisant toutes un peu la même chose
Ça marche plutôt bien pour les applications natives. C'est plus compliqué pour les applications portées depuis Linux ou il y a souvent plein de dépendances vers diverses bibliothèques et des problèmes de compatibilité qui surviennent très régulièrement. Pas trop d'accord avec l'auteur de l'article pour dire que c'est définitivement réglé, donc…
[^] # Re: Faites des paquets Debian pour vos applications
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne parlais pas de l'équipe core mais un niveau intermédiaire entre le système et les devs et c'est normalement ça les maintainers
:-)Ces dernier savent justement comment ça marche et les API et comment faire les choses proprement, alors que si tu demandes aux devs qui n'utilisent probablement pas le système ça va être le boxon. Mais bon, ces devs qui veulent garder tout le contrôle (ou pour des systèmes où il n'y a pas de personne/équipe dédiée à l'empaquetage), il y a flatpack et snap (et ce n'est pas définitivement réglé)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Faites des paquets Debian pour vos applications
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
On a pas le luxe chez Haiku d'être assez nombreux pour clairement séparer les deux. En théorie c'est le cas, les paquets pour les logiciels tiers sont gérés par Haikuports.
En pratique, les gens qui essaient de porter des logiciels trouvent des bugs dans le système et souvent finissent par les corriger eux-même. Et les gens qui développent l'OS veulent utiliser des logiciels ou bibliothèques qui ne sont pas encore packagées (ou pas dans la bonne version) et doivent le faire eux-même. Il y a donc une assez large intersection entre les deux équipes, et une seule association (Haiku inc) qui paie les serveurs et autres dépenses pour les deux projets.
Pour les applications natives, il n'y a pas vraiment besoin de passer par un "maintainer". Les développeurs d'applications sont aussi des utilisateurs de l'OS (ou même des développeurs de l'OS) et connaissent assez bien le système. Ce n'est pas très compliqué de distribuer un logiciel, soit sous forme d'un paquet hpkg, soit sous forme d'un simple fichier zip à décompresser.
Pour les applications portées, ça dépend, on a certains développeurs qui sont motivés pour faire les choses proprement, d'autres qui n'ont pas du tout envie de gérer des cas particuliers, et un peu de tout entre les deux.
Mais surtout, ce qui est important: on compte sur les utilisateurs pour se plaindre quand un logiciel est plus gros que l'installation de base de Haiku (quelques centaines de Mo).
[^] # Re: Faites des paquets Debian pour vos applications
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Est-ce que Flatpak est tombé en marche depuis https://linuxfr.org/nodes/118350/comments/1788497 ? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par ff9097 . Évalué à 3. Dernière modification le 23 novembre 2021 à 22:21.
Oui continuons à être open-bar et à donner absolument tout les droits à ce qu'on exécute !
# Linus et le packaging
Posté par flagos . Évalué à 4.
Ce lien n'est pas nouveau, mais c'est de circonstance
https://youtu.be/Pzl1B7nB9Kc
# Mouais
Posté par ff9097 . Évalué à 2.
On compare un système très mature comme le système de paquets mais où aucun format ni gestionnaire de paquets s'est imposé. On se retrouve donc aujourd'hui avec plusieurs formats qui sont tous un peu les mêmes en différents et pareil pour les gestionnaire de paquets. On est tous habitué au deb/rpm et apt/yum/… et ça continue par inertie.
Et de l'autre on a un système quasi-unique (je compte pas snap qui n'est poussé et n'est pris en charge que sur ubuntu) qui est encore très récent et dont pas mal de défauts mentionnés sont des choix qui peuvent être remis en cause facilement comme l'attribution de certaines permissions par défaut où le but était de ne pas trop changer les habitudes des utilisateurs.
Sur la sécurité c'est risible, actuellement c'est open-bar. Les applications ont tout les droits sur $HOME et même l'accés en lecture à /. Avec flatpak je retire les droits sans soucis si j'ai envie et sans bidouilles.
[^] # Re: Mouais
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Snap + AppImage + Flatpak, c'est pas vraiment quasi-unique. Surtout que ça ne remplace pas les autres solutions, ça ne fait qu'en rajouter encore plus.
[^] # Re: Mouais
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En plus, deb et rpm sont quasi aussi vieux et c'est pas pour cela que rpm a basculé sur deb… Et ils y a des défauts de jeunesse compliqué à changer.
Dans le calcul, on utilise plutôt Spark qui est plus adapté et au final, fonctionne mieux souvent que Nix ou Guix.
Bon, tout cela fait pas mal de diversité ;-)
# Super on se croirait un vendredi
Posté par Nodeus . Évalué à 3.
Et bien en voilà un tas de point de vue
# Pour les jeux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Les jeux ont une problématique spécifique:
Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?
Ce qui s'en rapproche le plus aujourd'hui:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par Renault (site web personnel) . Évalué à 3.
Flatpak testé et approuvé en LAN pour des tas de jeux libres : 0ad, supertuxkart, etc.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Mais pas Newton Adventure :( Cf https://linuxfr.org/nodes/118350/comments/1788497
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
On pourrait distribuer chaque jeu sur un support de stockage bootable contentant tout le code nécessaire, permettant à l'éditeur du jeu de choisir exactement ce qu'il inclut et de ne pas avoir de conflit entre les jeux.
Et on appellerait ça une console de jeux? ça serait simple et facile à utiliser.
[^] # Re: Pour les jeux
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 24 novembre 2021 à 13:47.
Je ne vois pas très bien de quoi tu parles, je possède une "console de jeux" à la maison, et non seulement les jeux ne sont pas tous sur un support dédié, mais en plus je dois régulièrement mettre à jour le système pour pouvoir lancer ces jeux, et le plus souvent ça prend des plombes. Tu es sûr qu'avoir "tout le code nécessaire" fait mieux fonctionner les choses ?
(le saviez-vous ? Windows CE n'était pas installé sur les Dreamcast, malgré la présence du logo sur la console. C'étaient les disques de jeu eux-même qui incluaient WinCE. La plupart ne s'en servaient pas de toute façon)
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 24 novembre 2021 à 14:39.
Les consoles sans même un BIOS, ça ne court pas les rues. Peut être la PC Engine et encore uniquement pour les jeux sur hucards?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
La NES et la SuperNES aussi, et la MegaDrive chez Sega. Je pense que la Nintendo 64 aussi mais je me trompe peut-être.
Pour la Game Boy et l'Atari Lynx il y a un BIOS de quelques centaines d'octets et qui ne peut pas être appelé par les jeux (il est là juste pour vérifier que la cartouche insérée est valide, et démarrer l'exécution du code).
Pour les consoles sans cartouches c'est effectivement plus compliqué.
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
Mais même une console qui aurait un noyau Linux et laisserait chaque jeu démarrer son propre userspace, ça marcherait peut être pas si mal que ça, et ça ressemblerait finalement assez aux Snap et Flatpak, en moins compliqué. Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 24 novembre 2021 à 19:11.
C'est que font les brouteurs web :-)
Mais c'est assez bloated. Il faudrait un brouteur jeu !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Tu oublies aussi la partie où les constructeurs vérifient chaque jeu un par un et leur font passer des semaines voire des mois en QA avant d'accepter leur commercialisation. Ça a été un sacré frein lorsque les premiers magasins dématérialisés ont commencé à ouvrir leurs portes aux devs indés, à la septième génération de consoles. Même aujourd'hui je doute que ce soit une promenade de santé pour les petits créateurs (parce que bien entendu, les gros n'en ont apparemment pas à s'en soucier, n'est-ce pas CD Projekt). Mine de rien, si on veut vraiment un ordinateur qui se comporte comme une console de jeux, ça existe déjà ; ça s'appelle l'iPad.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Sauf jouer sur iPad, faut aimer avoir très mal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Developers: Let distros do their job
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Dans le même esprit, on avait déjà ceci en septembre : https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par Pol' uX (site web personnel) . Évalué à 4.
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Je pense que dans de très fréquents cas (notamment en dev web), les développeurs n'envisagent pas ce que signifie pour les hébergeurs de maintenir 10 ans leur application à jour.
La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.
Adhérer à l'April, ça vous tente ?
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 0.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah tiens, on en parle au sujet d'un autre lien…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 1.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio
$ apt install moment-js
$ yum install python-trio
https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Je suis le mainteneur de quelques paquets sur NPM et PyPI, et je ne vois pas ce qui aurait pu m'empêcher d'y mettre n'importe quoi. Du coup, il me semble bien que faire confiance à un paquet sur NPM/PyPI revient à faire confiance au quidam qui l'a empaqueter.
Pour ma part, les paquets que j'ai mis sur NPM/PyPI ne dépendent d'aucun autre paquet dont je ne suis pas le mainteneur. C'est d'ailleurs un argument de « vente » de mes bibliothèques, cependant plus pour des considérations de légèreté que de sécurité.
Tiens, je viens de voir qu'il y a maintenant un bouton
Report malwaredans NPM…Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 25 novembre 2021 à 15:19.
Je me suis peut être mal exprimé.
La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.
Je ne compte plus le nombre de fois ou j'ai eu des soucis avec un
apt install python-proutqui s'est terminé par un virtualenv dans /opt.La confiance dont tu parles concerne la sécurité, et oui un dépôt officiel d'une distribution ou chaque contribution est revue par un organisme tier a plus de crédibilité qu'un dépôt communautaire (coucou AUR et archlinux?).
Maintenant, si dans ta société tu as les moyens pour une équipe en charge de la cybersécurité, ces derniers vont te fournir :
Si tu veux être parano et ne pas faire confiance a un quidam, tu l'es jusqu'au bout et tu ne fais pas confiance à un organisme tier sur lequel tu n'as aucun contrôle. En fait tu va vraiment jusqu'au bout et tu fais pas confiance à quelque chose qui a été produit par un humain.
https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Sur cet aspect, c'est possible que ce soit effectivement mieux géré. Cependant, pour des paquets qui embarquent du code natif, je me demande si passer par le gestionnaire de paquets de l'OS n'apporte pas certains avantages, sachant qu'on ne peut pas embarquer l'ensemble des codes natifs propres à chaque système d'exploitation et/ou architecture matériel ciblé avec les paquets NPM/PyPI qui l'utilisent.
J'ai fait des paquets NPM qui installent du code natif, et ce n'est pas simple. De mémoire, soit le code compilé pour la plateforme cible est disponible quelque part sur internet, et il le récupère, soit il lance une compilation, mais sans se préoccuper de la présence du compilateur adéquat.
Pour PyPI, je n'ai pas encore fait, mais c'est en projet, sachant qu'il existe des paquets sur PyPI qui le font et dont je compte bien m'inspirer. C'est peut-être plus facile, sachant que si Python est si populaire, c'est en grande partie grâce aux nombreuses bibliothèques tierces qui sont disponibles pour ce langage et dont les plus populaires s'appuient, pour beaucoup, sur du code natif…
Ceci dit, je n'ai jamais crée de paquets pour une quelconque distribution Linux, donc je ne peux pas m'avancer sur les avantages/inconvénients de cette méthode par rapport à l'utilisation de NPM/PyPI…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 1.
Oof, tu piques la où ça fait mal ! C'est pas très fair play :p
Pour PyPI, tu as les wheels qui sont des paquets précompilés. Tu en as pour la glibc et pour Windows.
Attention par contre : https://pythonspeed.com/articles/alpine-docker-python/
Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans
C:\Program Files/opt. C'est juste plus simple.https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par Claude SIMON (site web personnel) . Évalué à 2.
J'essayais juste de trouver pour quelle raison on pouvait préférer le gestionnaire de paquets de l'OS plutôt que le dédié :-).
Je viens juste de comprendre le fonctionnement des wheels. En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
Concrètement, on a une section, dans le package.json, qui ressemble à ça :
Ça permet à NPM de construire l'URL où récupérer le code natif pour la plateforme ciblée (noter le
{platform}-{arch}pour l'entréepackage_name, dont on trouve l'équivalent dans le nommage des wheels de PyPI), à charge pour l'empaqueteur d'y placer le fichier adéquat.En fait, c'est
node-[pre-]gypqui s'occupe de la récupération, et on peut lui indiquer de lancer la compilation s'il ne trouve pas le fichier attendu. Ce qui, le cas échéant, ne peut évidemment fonctionner que si le compilateur adéquat et présent…Ceci
ditécrit, même si les binaires sont disponibles sur PyPI à travers les wheels, c'est quand même à l'empaqueteur de les générer, ou bien ?Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 1. Dernière modification le 25 novembre 2021 à 19:44.
Good to know :)
T'as de l'outillage pour t'aider à les générer, mais sur le principe oui, si l'empaqueteur ne les fournis pas, personne va les fournir pour toi.
Tu as par exemple des images Docker pour te fournir une alpine/debian/ubuntu avec un JDK dans une version spécifique. Pareil pour Python, Erlang/Elixir, etc…
Fun fact, j'ai une application Elixir qui embarque dans son image Docker un binaire Go, dans la phase de build j'ai ceci:
COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
ENV PATH="/usr/local/go/bin:${PATH}"
Alors certes, j'imagine mal une image Docker "python-django" ou "node-expressjs" sur DockerHub. Cependant j'ai pas mal vu en entreprise des images Docker de base du style "java-jdk11-springboot" partagées entre les différentes teams.
Accessoirement, pour Windows si tu veux bosser avec la SDL, tu chope un ZIP qui te donne les headers et les DLLs.
https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par Faya . Évalué à 2.
Avant d'installer un paquet de AUR on conseille fortement :
* de lire les commentaires
* de lire le fichier PKGBUILD qui te montre exactement ce qui sera téléchargé et où ça va être installé.
C'est écrit en gros, partout. En général on est en mesure de s'assurer que la source est bien "officielle" (le dépôt Github du développeur par ex.) M'enfin oui ce n'est pas comparable avec des paquets revus par les mainteneurs d'une distro. Cela dit c'est pas la même chose avec les PPA de Ubuntu ? (vraie question, je n'ai pas utilisé depuis longtemps)
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 1.
C'est le même problème avec tout les dépôts communautaires sans review.
Les teams DevSecOps me chuchotent à l'oreille que ces conseils s'appliquent à toutes les dépendances externes peu importe leurs provenance (dépôt officiel ou non).
https://link-society.com - https://kubirds.com
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 25 novembre 2021 à 14:15.
Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.
La maintenance à long terme demande:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par Renault (site web personnel) . Évalué à 5.
Même si toutes les distributions utiliseraient RPM, le problème ne serait pas résolu. Ce serait un progrès mais insuffisant.
Déjà car chaque distribution nomme ses paquets de manière différentes. Si c'est souvent le même, parfois c'est très différent. Pensons à kernel chez Red-Hat pour linux côté Debian. Ou Apache pour Debian, httpd pour Red Hat. Du coup pour les dépendances d'un paquet ça pose problème.
Ensuite les options de compilation et le découpage des paquets (et de fait les dépendances) sont différentes. Certaines distributions peuvent faire un gros paquet Libreoffice qui fournit tout, quand d'autres vont avoir un paquet par logiciel fourni par Libreoffice. L'un est plus simple, l'autre permet d'être plus modulaire (et donc potentiellement n'installer que ce qui est vraiment nécessaire). Il n'y a pas de choix parfaits à ce sujet.
Cela dépend moins des distributions que de la chaine de compilation et des bibliothèques employées par les logiciels fournis. Ce n'est pas de la faute de Fedora ou Debian si GNOME migre vers GTK4 qui n'est pas compatible avec GTK+3 par exemple.
C'est l'avantage du libre, tu peux composer ce que tu veux selon tes envies et besoin, l'inconvénient c'est qu'il fragmente l'écosystème et rend la tâche plus complexe pour les personnes extérieures. Flatpak est un moyen (comme d'autres) de résoudre ce conflit, mais là encore cette solution a des inconvénients.
À un moment il faut réaliser qu'il n'y a aucune solution technique parfaite, et que d'aller dans un sens a un impact négatif sur d'autres paramètres.
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Peut être que l'approche "empaquetage" est mauvaise alors.
En tout cas la conséquence, c'est que tout fini dans /opt ou sur docker…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par Renault (site web personnel) . Évalué à 3. Dernière modification le 25 novembre 2021 à 14:56.
Elle a ses avantages et ses inconvénients.
Si tu supprimes les paquets pour la faire à la macOS ou Windows, ça va certes améliorer cet aspect significativement, mais ça va râler dans les chaumières.
Notons que par exemple Fedora Silverblue comme d'autres tentent une approche nouvelle, qui n'est pas parfaite mais a son intérêt.
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . Évalué à 1.
Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
https://link-society.com - https://kubirds.com
# Une réponse de Will Thompson (Endless OS)
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 novembre 2021 à 14:58.
Pour ceux qui l'ignorent, Endless OS est une distribution qui utilise exclusivement les flatpaks pour gérer ses paquets (sur le même principe que Fedora Silverblue si je ne m'abuse). Un des employés d'Endless, Will Thompson, a voulu calculer l'espace disque que ça lui occupait (puisque l'un des reproches faits dans le billet de Ludocode est que Flatpak prend trop de place). Un aperçu :
[^] # Re: Une réponse de Will Thompson (Endless OS)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Lien publié et discuté justement : https://linuxfr.org/users/flagos/liens/on-flatpak-disk-usage-and-deduplication
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.