Dn même temps les rpm est associés c'était déjà fait justement pour pouvoir installer sans se préoccuper de rien et compiler. Un nouveau format de package ne résoudra rien.
Le format de package magique comment il sait avec quelle version de bibliothèque fonctionner ? Sous windows ça marche parce que le parc est*tres* uniforme coté OS, et que la plupart des appli fournissent toutes les dépendances à chaque fois, (tout à retélécharger).
Sous Linux on est beaucoup plus en dynamique, on a beaucoup de différences d'une machine à l'autre .... tu peux bien faire un joli package à la "install shield", ça ne changera pas les problématiques et tu te retrouveras avec une version du package pour chaque distro.
Pire, sous Linux on a une intégration beaucoup plus forte des logiciels. Je peux par exemple parler de bête menu gnome/kde qui n'est pas organisé avec un sous menu par application mais par thème/but. Les thèmes et l'orientation ne sera pas la même suivant les distros, impossible d'avoir une intégration "habituelle" sans faire du spécifique. Windows a choisi de ne pas se préoccuper de ce genre d'intégration, moi j'aimerai qu'on évite de mettre une croix sur ce genre de choses intéressantes sous Linux.
Après tu peux faire une version unique en compilant le principal en statique et en ne te basant que sur quelques valeurs sûres, mais ça veut dire compiler en statique (consommation mémoire) et ne pas marcher sur les distro ou installation non courantes.
Ceci dit les packages statiques ça existe déjà. OpenOffice en a un, Mozilla aussi, Apache aussi, Mysql aussi.... En général c'est un simple tar.gz qui contient les binaires et qu'il suffit de décompresser. Je ne suis pas sûr que ce soit forcément un mieux que d'avoir un superbe package exécutable pour remplacer.
En tout cas ça ne sera pas et ça ne peux pas être la solution magique à la multiplication des rpm, c'est juste un nouveau format, rien de plus. Si c'était si simple on aurait unifié depuis longtemps les rpm au lieu d'en avoir 150 versions. Si ce n'est pas fait c'est que le problème n'est pas au niveau du conteneur (format de package) mais au niveau du contenu.
# mouais
Posté par Éric (site web personnel) . En réponse au journal Autopackage.... Évalué à 6.
Le format de package magique comment il sait avec quelle version de bibliothèque fonctionner ? Sous windows ça marche parce que le parc est*tres* uniforme coté OS, et que la plupart des appli fournissent toutes les dépendances à chaque fois, (tout à retélécharger).
Sous Linux on est beaucoup plus en dynamique, on a beaucoup de différences d'une machine à l'autre .... tu peux bien faire un joli package à la "install shield", ça ne changera pas les problématiques et tu te retrouveras avec une version du package pour chaque distro.
Pire, sous Linux on a une intégration beaucoup plus forte des logiciels. Je peux par exemple parler de bête menu gnome/kde qui n'est pas organisé avec un sous menu par application mais par thème/but. Les thèmes et l'orientation ne sera pas la même suivant les distros, impossible d'avoir une intégration "habituelle" sans faire du spécifique. Windows a choisi de ne pas se préoccuper de ce genre d'intégration, moi j'aimerai qu'on évite de mettre une croix sur ce genre de choses intéressantes sous Linux.
Après tu peux faire une version unique en compilant le principal en statique et en ne te basant que sur quelques valeurs sûres, mais ça veut dire compiler en statique (consommation mémoire) et ne pas marcher sur les distro ou installation non courantes.
Ceci dit les packages statiques ça existe déjà. OpenOffice en a un, Mozilla aussi, Apache aussi, Mysql aussi.... En général c'est un simple tar.gz qui contient les binaires et qu'il suffit de décompresser. Je ne suis pas sûr que ce soit forcément un mieux que d'avoir un superbe package exécutable pour remplacer.
En tout cas ça ne sera pas et ça ne peux pas être la solution magique à la multiplication des rpm, c'est juste un nouveau format, rien de plus. Si c'était si simple on aurait unifié depuis longtemps les rpm au lieu d'en avoir 150 versions. Si ce n'est pas fait c'est que le problème n'est pas au niveau du conteneur (format de package) mais au niveau du contenu.