Si tu lis mes réponses, tu verras que j'argumente, que j'expose les informations dont je dispose, qui contredisent les "faits" balancé par mon interlocuteur.
Pas dans celui que j'ai cité.
Ce n'est pas au développeur d'application de faire ce travail, mais au mainteneur de la distribution.
Ça ne marche pas et ça ne marchera pas dans l'avenir. Les distributions ont de plus en plus de mal à avoir des contributeurs, le nombre de logiciels est croissants,... Cette découpe cathédralesque « tout le monde reste chez soit et les moutons seront bien gardé » ne fonctionne pas, ce n'est pas ce qui est fait dans tous les systèmes où le packaging n'est pas un problème et où on a un foisonnement de logiciels. On y croyait dans les années 90, mais ça devient compliqué à tenir et ça ne va pas en s’arrangeant. Si c'était réellement le cas on aurait pas vu arriver autant de système de paquets arrivés pour combler un besoin qui n'existerait pas. Les développeurs debian sont satisfait de dpkg.
C'est ce qu'il fait pour Windows, et Mac de toute façon, sauf que ça s'appelle par "tar.gz".
Ce n'est pas ce qu'il font. Très peu d'utilisateurs de windows et mac ont une véritable toolchaine sur leur machine. Sur windows les gens font pas mal d'installeur et sous mac ça se rapporche (il me semble) d'un appimage mais mieux intégré (le finder les prends automatiquement en compte) et aujourd'hui les 2 poussent vers un store, mais ce n'est pas comme les dépôts debian/redhat, les développeurs poussent eux même leurs paquets.
Mais travailler activement avec l'upstream de la distro pour intégrer le package au reste du système ? Non, définitivement, c'est pas le taf du dev.
Quelque soit la manière permettre aux développeurs de fournir un paquet aux utilisateurs linux, qui soit correctement installés (inclus dans le launcher et dans le $PATH à minima) sans devoir attendre le bon vouloir des distribution ou sans que ça représente une charge de travail en plus pour elles. Aujourd'hui on s'en approche à peu prêt (on reste avec au moins 2 solutions très distinctes dans leur utilisation - donc l'utilisateur doit connaître les 2 -), mais ça demande encore du travail.
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à 3.
Pas dans celui que j'ai cité.
Ça ne marche pas et ça ne marchera pas dans l'avenir. Les distributions ont de plus en plus de mal à avoir des contributeurs, le nombre de logiciels est croissants,... Cette découpe cathédralesque « tout le monde reste chez soit et les moutons seront bien gardé » ne fonctionne pas, ce n'est pas ce qui est fait dans tous les systèmes où le packaging n'est pas un problème et où on a un foisonnement de logiciels. On y croyait dans les années 90, mais ça devient compliqué à tenir et ça ne va pas en s’arrangeant. Si c'était réellement le cas on aurait pas vu arriver autant de système de paquets arrivés pour combler un besoin qui n'existerait pas. Les développeurs debian sont satisfait de dpkg.
Ce n'est pas ce qu'il font. Très peu d'utilisateurs de windows et mac ont une véritable toolchaine sur leur machine. Sur windows les gens font pas mal d'installeur et sous mac ça se rapporche (il me semble) d'un appimage mais mieux intégré (le finder les prends automatiquement en compte) et aujourd'hui les 2 poussent vers un store, mais ce n'est pas comme les dépôts debian/redhat, les développeurs poussent eux même leurs paquets.
Quelque soit la manière permettre aux développeurs de fournir un paquet aux utilisateurs linux, qui soit correctement installés (inclus dans le launcher et dans le $PATH à minima) sans devoir attendre le bon vouloir des distribution ou sans que ça représente une charge de travail en plus pour elles. Aujourd'hui on s'en approche à peu prêt (on reste avec au moins 2 solutions très distinctes dans leur utilisation - donc l'utilisateur doit connaître les 2 -), mais ça demande encore du travail.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll