Je pense que l'une des raisons majeures, c'est l'historique.
Plusieurs distros ont fait leur format, parce que celui du voisin ne permettait pas de faire un truc qu'elles voulaient absolument ( non, je n'ai pas d'exemple, dans le monde linux, je suis bien trop jeune. Ceci dit, je suis un programmeur, donc je peux imaginer le truc d'ici. Par exemple, les paquets suggérés pouvaient ne pas exister dans un format, ou la signature numérique du mainteneur, etc ).
Depuis, les formats ont, forcément, vu que c'est libre, récupéré les fonctionnalités des autres qui leurs semblaient intéressantes ( pas nécessairement toutes, par exemple, je suis persuadé qu'un paquet gentoo permets bien plus de souplesse qu'un deb au niveau des dépendances ).
Mais parallèlement, les outils manipulant ces formats ont évolué, eux aussi, les distros se sont bâties sur ces outils complexes ( bah oui, résoudre des dépendances, et trouver des solutions optimales automatiquement, ce n'est pas quelque chose de simple, surtout quand une demande de l'utilisateur casse un autre paquet. Dans ce genre de cas, aptitude par exemple, proposera plusieurs solutions ) et donc migrer vers le format du voisin serait inutilement coûteux et complexe.
Après, même si les paquets binaires sont probablement très semblables en terme de nombre de fonctionnalités, je ne crois pas que ce soit le cas avec les distros source, non plus.
Donc, même si je suis prêt à admettre que c'est un problème, je pense également que le remédier est hyper complexe sinon impossible, l'humain derrière la machine étant un appareil dont il est difficile de prévoir le comportement ou de l'orienter, à plus forte raison quand on prône la liberté.
Et puis, franchement, il faudrait arrêter de dire que c'est compliqué de faire un paquet... dans le cas de Debian ( je ne connais que ça, navré, mais à ce que je peux lire un peu partout ça semble le format le plus pénible? ) par exemple, il suffit de recréer l'arborescence ou l'on souhaite envoyer les fichiers, les y placer, et à la racine de cette arborescence, créer un dossier DEBIAN contenant un fichier control, ou l'on écrit les dépendances, la description, le nom du mainteneur, l'architecture cible, etc.
Une fois tout ça fait, on remonte d'un dossier, et on tape: dpkg-deb -b
C'est pas complet ( pas de hash pour l'intégrité des données, notamment, parce que pour ça, il faut un autre fichier avec les hash de chaque fichier. Je n'ai pas encore regardé comment ça marche, mais ça ne doit pas casser 3 pattes à un canard... ), et ça ne sera jamais intégré tel que dans Debian bien sûr, mais ça marche et c'est bien plus propre que du "./configure && make && sudo make install".
Maintenant, le but du développeur ne devrait pas nécessairement être l'intégration dans une distribution, mais que le logiciel soit utilisable facilement, quitte à lui demander d'ajouter un dépôt s'il veut des MaJ automatiques ( et puisqu'on compare avec la concurrence, je rappelle que la concurrence ne fait que commencer à s'y mettre, aux MaJ auto des softs installés... ) chose qui n'est même pas obligatoire: pas besoin du dépôt complet pour double cliquer sur le .deb ( ou lancer un dpkg -i, mais c'est juste parce que moi, je n'ai pas d'explorateur de fichiers. )
Après, c'est sûr, je ne connais que Debian, et en conséquent, je ne fais les paquets de mes outils que pour Debian. En même temps, les gens qui font des outils pour windows, quand ils acceptent de fournir un installateur, ne le fournissent pas pour Mac OS... et je considère que deux distributions sont des systèmes d'exploitation différents ( même si c'est techniquement inexact ).
Ce qui ne m'empêchera jamais d'accepter un script pour bâtir un rpm, si quelqu'un m'en fournit un.
Dernière phrase qui me permets de rappeler ce principe élémentaire du libre:
Les développeurs sont libres d'améliorer leurs logiciels, mais les utilisateurs sont aussi libres d'y contribuer. Dans les deux cas, les gens ont le choix de faire ou de ne pas faire, mais je trouve malhonnête ce genre de phrases:
En plus, c'est une tache ingrate, je me dis quel si la moitié des créateurs de paquets consacraient ce temps à, par exemple, écrire de la documentation, l'univers du libre ne s'en porterai pas plus mal.
La documentation, c'est plus censé être le boulot des développeurs, d'une part, sauf que ça les ( nous? ) fait chier, profondément. Les intégrateurs, ou packageurs, sont censés utiliser cette doc pour fournir un mécanisme d'installation propre pour un système donné.
Bref.
Et toi, qui affirme relativement fièrement que ça te fait chier de "perdre ton temps" à contribuer, comment peux-tu dire ce que les autres devraient faire, si tu ne mets pas la main à la pâte? Yakafokon? Ou alors peut-être contribues-tu, et dans ce cas, peut-être serait-il plus constructif de nous dire quels problèmes exacts tu as rencontré, parce que je n'ai vu aucun problème concret dans ton journal ( bien que je sais qu'il en existe, ce serait stupide de le nier, mais c'est toujours mieux un argumentaire avec de vrais morceaux d'arguments bien formés dedans )
# L'histoire
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 10.
Je pense que l'une des raisons majeures, c'est l'historique.
Plusieurs distros ont fait leur format, parce que celui du voisin ne permettait pas de faire un truc qu'elles voulaient absolument ( non, je n'ai pas d'exemple, dans le monde linux, je suis bien trop jeune. Ceci dit, je suis un programmeur, donc je peux imaginer le truc d'ici. Par exemple, les paquets suggérés pouvaient ne pas exister dans un format, ou la signature numérique du mainteneur, etc ).
Depuis, les formats ont, forcément, vu que c'est libre, récupéré les fonctionnalités des autres qui leurs semblaient intéressantes ( pas nécessairement toutes, par exemple, je suis persuadé qu'un paquet gentoo permets bien plus de souplesse qu'un deb au niveau des dépendances ).
Mais parallèlement, les outils manipulant ces formats ont évolué, eux aussi, les distros se sont bâties sur ces outils complexes ( bah oui, résoudre des dépendances, et trouver des solutions optimales automatiquement, ce n'est pas quelque chose de simple, surtout quand une demande de l'utilisateur casse un autre paquet. Dans ce genre de cas, aptitude par exemple, proposera plusieurs solutions ) et donc migrer vers le format du voisin serait inutilement coûteux et complexe.
Après, même si les paquets binaires sont probablement très semblables en terme de nombre de fonctionnalités, je ne crois pas que ce soit le cas avec les distros source, non plus.
Donc, même si je suis prêt à admettre que c'est un problème, je pense également que le remédier est hyper complexe sinon impossible, l'humain derrière la machine étant un appareil dont il est difficile de prévoir le comportement ou de l'orienter, à plus forte raison quand on prône la liberté.
Et puis, franchement, il faudrait arrêter de dire que c'est compliqué de faire un paquet... dans le cas de Debian ( je ne connais que ça, navré, mais à ce que je peux lire un peu partout ça semble le format le plus pénible? ) par exemple, il suffit de recréer l'arborescence ou l'on souhaite envoyer les fichiers, les y placer, et à la racine de cette arborescence, créer un dossier DEBIAN contenant un fichier control, ou l'on écrit les dépendances, la description, le nom du mainteneur, l'architecture cible, etc.
Une fois tout ça fait, on remonte d'un dossier, et on tape: dpkg-deb -b
C'est pas complet ( pas de hash pour l'intégrité des données, notamment, parce que pour ça, il faut un autre fichier avec les hash de chaque fichier. Je n'ai pas encore regardé comment ça marche, mais ça ne doit pas casser 3 pattes à un canard... ), et ça ne sera jamais intégré tel que dans Debian bien sûr, mais ça marche et c'est bien plus propre que du "./configure && make && sudo make install".
Maintenant, le but du développeur ne devrait pas nécessairement être l'intégration dans une distribution, mais que le logiciel soit utilisable facilement, quitte à lui demander d'ajouter un dépôt s'il veut des MaJ automatiques ( et puisqu'on compare avec la concurrence, je rappelle que la concurrence ne fait que commencer à s'y mettre, aux MaJ auto des softs installés... ) chose qui n'est même pas obligatoire: pas besoin du dépôt complet pour double cliquer sur le .deb ( ou lancer un dpkg -i, mais c'est juste parce que moi, je n'ai pas d'explorateur de fichiers. )
Après, c'est sûr, je ne connais que Debian, et en conséquent, je ne fais les paquets de mes outils que pour Debian. En même temps, les gens qui font des outils pour windows, quand ils acceptent de fournir un installateur, ne le fournissent pas pour Mac OS... et je considère que deux distributions sont des systèmes d'exploitation différents ( même si c'est techniquement inexact ).
Ce qui ne m'empêchera jamais d'accepter un script pour bâtir un rpm, si quelqu'un m'en fournit un.
Dernière phrase qui me permets de rappeler ce principe élémentaire du libre:
Les développeurs sont libres d'améliorer leurs logiciels, mais les utilisateurs sont aussi libres d'y contribuer. Dans les deux cas, les gens ont le choix de faire ou de ne pas faire, mais je trouve malhonnête ce genre de phrases:
La documentation, c'est plus censé être le boulot des développeurs, d'une part, sauf que ça les ( nous? ) fait chier, profondément. Les intégrateurs, ou packageurs, sont censés utiliser cette doc pour fournir un mécanisme d'installation propre pour un système donné.
Bref.
Et toi, qui affirme relativement fièrement que ça te fait chier de "perdre ton temps" à contribuer, comment peux-tu dire ce que les autres devraient faire, si tu ne mets pas la main à la pâte? Yakafokon? Ou alors peut-être contribues-tu, et dans ce cas, peut-être serait-il plus constructif de nous dire quels problèmes exacts tu as rencontré, parce que je n'ai vu aucun problème concret dans ton journal ( bien que je sais qu'il en existe, ce serait stupide de le nier, mais c'est toujours mieux un argumentaire avec de vrais morceaux d'arguments bien formés dedans )