T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de .tar.gz je ne sais pas de quoi tu parle. Les .tar.gz dont on parle classiquement sont des sources qui demandent ./configure.sh && make && make install.
Ces applications de l'utilisateur ont juste besoin d'être trouvable dans le PATH et d'avoir un .desktop quelque part. Il existe une solution hyper simple :
Avoir un truc du style /apps/*/bin dans le PATH qui soit supporté par les shell
Avoir le même système pour les .desktop: /apps//.desktop
Cette solution est à implémenter au niveau de la distribution. Ensuite, il s'agit d'extraire un .tar.gz dans le dossier /apps.
Tout le monde à le droit écrire dans ce /apps ? Il n'est pas définir par HFS actuellement, /opt peut mais il n'est pas aussi normalisé. Comment tu met à jour tout ça ?
Mais du coup ta solution pour dire qu'il n'y a pas de problème avec les systèmes de paquets c'est d'en concevoir un nouveau ?
Et qui a fait ça ? Les mainteneurs de Mac OS, pas les devs de l'appli.
On ne doit pas être d'accord sur les termes, mais du coup je ne comprends pas quel point de vu tu me donne. Ce dont tu parle c'est d'un système de paquet mis en place par les développeurs d'Apple, mais le boulot de packaging est fait par les développeurs d'application. Comme je le disais dans mon commentaire : une solution qui permet aux développeurs d'application de fournir un logiciel sans que ça n'ajoute du travail aux développeurs Apple.
Mais cet installeur n'a toujours comme seul rôle d'extraire une archive qui contient tout ce dont elle a besoin.
Les gestionnaires de paquets :
pausent les binaires et les assets
font l'intégration pour pouvoir lancer le programme
ajouter au $PATH et au lancher
lui donner les droits nécessaires (créer un utilisateur, positionner les droits posix)
ajouter les man à la db de man
permettre la suppression et la mise à jour de tout ça sans rien oublié
Et ce travail n'est pas a être fait par le développeur de l'application.
Le boulot de créer des package doit revenir au développeurs des applications à packager.
Le boulot de créer les systèmes de paquets doit revenir aux développeurs de distribution.
Le point initial c'est "la difficulté à créer un package qui soit utilisable à peu près partout sans difficulté est un problème".
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à 0.
T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de
.tar.gzje ne sais pas de quoi tu parle. Les.tar.gzdont on parle classiquement sont des sources qui demandent./configure.sh && make && make install.Tout le monde à le droit écrire dans ce /apps ? Il n'est pas définir par HFS actuellement, /opt peut mais il n'est pas aussi normalisé. Comment tu met à jour tout ça ?
Mais du coup ta solution pour dire qu'il n'y a pas de problème avec les systèmes de paquets c'est d'en concevoir un nouveau ?
On ne doit pas être d'accord sur les termes, mais du coup je ne comprends pas quel point de vu tu me donne. Ce dont tu parle c'est d'un système de paquet mis en place par les développeurs d'Apple, mais le boulot de packaging est fait par les développeurs d'application. Comme je le disais dans mon commentaire : une solution qui permet aux développeurs d'application de fournir un logiciel sans que ça n'ajoute du travail aux développeurs Apple.
Les gestionnaires de paquets :
Le boulot de créer des package doit revenir au développeurs des applications à packager.
Le boulot de créer les systèmes de paquets doit revenir aux développeurs de distribution.
Le point initial c'est "la difficulté à créer un package qui soit utilisable à peu près partout sans difficulté est un problème".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll