> L'utopie voudrait donc qu'un nouveau format de paquets [...] fasse son apparition
Et encore, ça ne résoudrait pas grand chose. On pense souvent que le problème vient du fait que le format DEB et le format RPM sont différents, mais quand on creuse on se rend compte que c'est faux. Exemple : je suis sur Fedora, je vais chercher sur rpmfind.net un paquet lambda qui correspond à mon application manquante. Il se trouve que le paquet vient de chez SuSE ou Mandriva, sur une version n-2, et donc forcément quand j'essaye de l'installer, je me fais jeter.
Et pourtant, c'est bien un RPM.
Le problème de compatibilité entre les paquets des distributions ne vient pas du format, mais du fait qu'ils sont compilés avec des bibliothèques différentes, pas forcément compatibles, avec des options différentes, etc.
En fait, le problème vient du fait que les paquets viennent de distributions différentes.
C'est là d'ailleurs le fond du problème : supposer que n'importe quel RPM peut s'installer sur n'importe quelle distribution basée sur RPM, c'est ignorer (voire nier) le travail de mise en cohérence fait par la distribution.
Et au passage, les deux formats ne sont pas si différents l'un de l'autre. En gros une archive, des méta-données décrivant le paquet et ses dépendances, et des scripts à exécuter autour de l'installation et de la désinstallation du paquet. On fait tout un foin sur les incompatibilités entre ces deux formats, alors que le problème n'est pas là.
Il y a selon moi quatre solutions au problème pour un distributeur de logiciel externe, si on exclut l'inclusion dans la distribution bien sûr :
- la compilation statique
- la fourniture, avec le programme, de ses bibliothèques dynamiques dans un dossier à part. C'est ce qui se fait le plus en ce moment (mozilla, jeux, etc.), mais c'est pas beaucoup mieux que la compilation statique
- l'utilisation d'un format spécifique type autopackage ou klik (le truc de SuSE qui monte dynamiquement une image iso)
- la distribution sous forme de source, avec peut-être un système pour créer automatiquement un package en local (type checkinstall)
Aucune de ces solutions ne semble miraculeuse, sachant qu'elles sont toutes un pis-aller à l'inclusion dans la distribution.
Autopackage n'a jamais vraiment décollé, c'est dommage je trouve. Des avis ?
[^] # Re: Paquets universels ?
Posté par Aurélien Bompard (site web personnel) . En réponse à la dépêche CUDF, ou la résolution de dépendances universelle. Évalué à 5.
Et encore, ça ne résoudrait pas grand chose. On pense souvent que le problème vient du fait que le format DEB et le format RPM sont différents, mais quand on creuse on se rend compte que c'est faux. Exemple : je suis sur Fedora, je vais chercher sur rpmfind.net un paquet lambda qui correspond à mon application manquante. Il se trouve que le paquet vient de chez SuSE ou Mandriva, sur une version n-2, et donc forcément quand j'essaye de l'installer, je me fais jeter.
Et pourtant, c'est bien un RPM.
Le problème de compatibilité entre les paquets des distributions ne vient pas du format, mais du fait qu'ils sont compilés avec des bibliothèques différentes, pas forcément compatibles, avec des options différentes, etc.
En fait, le problème vient du fait que les paquets viennent de distributions différentes.
C'est là d'ailleurs le fond du problème : supposer que n'importe quel RPM peut s'installer sur n'importe quelle distribution basée sur RPM, c'est ignorer (voire nier) le travail de mise en cohérence fait par la distribution.
Et au passage, les deux formats ne sont pas si différents l'un de l'autre. En gros une archive, des méta-données décrivant le paquet et ses dépendances, et des scripts à exécuter autour de l'installation et de la désinstallation du paquet. On fait tout un foin sur les incompatibilités entre ces deux formats, alors que le problème n'est pas là.
Il y a selon moi quatre solutions au problème pour un distributeur de logiciel externe, si on exclut l'inclusion dans la distribution bien sûr :
- la compilation statique
- la fourniture, avec le programme, de ses bibliothèques dynamiques dans un dossier à part. C'est ce qui se fait le plus en ce moment (mozilla, jeux, etc.), mais c'est pas beaucoup mieux que la compilation statique
- l'utilisation d'un format spécifique type autopackage ou klik (le truc de SuSE qui monte dynamiquement une image iso)
- la distribution sous forme de source, avec peut-être un système pour créer automatiquement un package en local (type checkinstall)
Aucune de ces solutions ne semble miraculeuse, sachant qu'elles sont toutes un pis-aller à l'inclusion dans la distribution.
Autopackage n'a jamais vraiment décollé, c'est dommage je trouve. Des avis ?