il faudra en plus télécharger ou fournir avec le précédent paquet binaire TOUTES les dépendances nécessaires et qui ne sauraient être fournies par la distribution cible
ça c'est l'inconvénient. Il convient donc de préciser plusieurs chose:
1) le binaire prêt à l'emploi, c'est pour un logiciel final "basique" ne dépendant de pas de trop de trucs en dehors d'une LSB 3.2. A partir du moment ou on aura une LSB 3.2 avec gtk, qt, python, beaucoup de logiciels destinés aux utilisateurs finaux pourraont fournir un binaire incluant les qualques libs qui manquent.
Dans le cas de gcompris, les dépendances ça doit être LSB 3.2 (gtk, python, pygtk) + SDL_mixer (et donc SDL) plus sqlite3 et pysqlite2 plus libgnomecanvas. J'en oublie peut-être une ou deux mais pas plus. Dans ces conditions ça reste raisonnable de penser fournir un bundle x86 prêt à l'emploi pour toute distribution compatible LSB 3.2
Si LSB n'a pas cet intérêt là, il ne sert à rien.
2) Et dans ce cas, je te laisse imaginer, même en prenant bien soin de les installer à l'écart, dans /usr/local ou /opt, les conflits que cela peut encore générer malgré tout avec les bibliothèques déjà présentes sur le système et notamment les logiciels qui en dépendraient. Dans le meilleur des mondes, ça ne devrait pas gêner.
La solution à laquelle je pense, c'est de ne pas installer les libs en questions mais les mettre dans un bundle. Avec un wrapper comme celui utiliser par autopackage pour positionner correctement LD_LIBRARY_PATH avant de lancer l'éxecutable.
En théorie on peut mettre comme ça même un truc aussi gros que GTK (si on a besoin d'une version différente de celle de la LSB en cours, ce qui n'est pas le but) sans casser le système hote.
Je crois savoir que Google Earth marche comme ça, en fournissant son QT (il ne peut pas utiliser le QT/GPL).
Mais le but, c'est d'avoir une solution efficace (le bundle) utilisable pour des logiciels finaux sans trop de complexité. Il y a beaucoup de projets qui dépendent de GTK < 2.8, qui n'ont pas besoin des dernières versions de gtk. Dans ce cas une bundle prêt à tourner sur toute distrib compatible LSB 3.2 est tout à fait envisageable.
3) le but n'est ni de se substituer à un packaging de distribution, bien meilleure solution. C'est de pouvoir proposer une version à utiliser facilement sans casser les distribution, sans devoir attendre que la distribution ait mis à jour les paquets, et sur laquelle ont puisse demander de tester les corrections de bugs rapportés.
En gros je peux faire un AppDir que Rox considère comme un programme à lancer en utilisant comme base le wrapper d'autopackage pour positionner LD_LIBRARY_PATH. Mais il n'y a que Rox avec lequel il suffise de poser ça dans ~/App pour que ça apparaisse dans les menus. C'est la solution NextStep (et donc osX) . L'idéal serait que freedesktop en fasse une norme que Kde et Gnome (et les autres) intègrent.
On peut même imaginer que l'installeur debian fasse le tour des Appdir à l'installation/MàJour d'un logiciel pour signaler par mail à root que des bundle du même programme trainent sur le système, ça peut être une info intéressante (nettoyage tout ça). Mais ça nécessite que les bundle soient les même pour tous.
Avec autopackage/OBCLICK/klik... on multiplie les solutions, preuve qu'un réel besoin existe. Un standard de travail pour tous les bureaux, c'est le but de freedesktop. Je trouve que le bundle d'application à la NextStep manque dedans. Et que ça serait une meilleure solution que celle proposée par Ian Murdoch.
[^] # Re: Ça n'arriveras jamais
Posté par fleny68 . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
ça c'est l'inconvénient. Il convient donc de préciser plusieurs chose:
1) le binaire prêt à l'emploi, c'est pour un logiciel final "basique" ne dépendant de pas de trop de trucs en dehors d'une LSB 3.2. A partir du moment ou on aura une LSB 3.2 avec gtk, qt, python, beaucoup de logiciels destinés aux utilisateurs finaux pourraont fournir un binaire incluant les qualques libs qui manquent.
Dans le cas de gcompris, les dépendances ça doit être LSB 3.2 (gtk, python, pygtk) + SDL_mixer (et donc SDL) plus sqlite3 et pysqlite2 plus libgnomecanvas. J'en oublie peut-être une ou deux mais pas plus. Dans ces conditions ça reste raisonnable de penser fournir un bundle x86 prêt à l'emploi pour toute distribution compatible LSB 3.2
Si LSB n'a pas cet intérêt là, il ne sert à rien.
2) Et dans ce cas, je te laisse imaginer, même en prenant bien soin de les installer à l'écart, dans /usr/local ou /opt, les conflits que cela peut encore générer malgré tout avec les bibliothèques déjà présentes sur le système et notamment les logiciels qui en dépendraient. Dans le meilleur des mondes, ça ne devrait pas gêner.
La solution à laquelle je pense, c'est de ne pas installer les libs en questions mais les mettre dans un bundle. Avec un wrapper comme celui utiliser par autopackage pour positionner correctement LD_LIBRARY_PATH avant de lancer l'éxecutable.
En théorie on peut mettre comme ça même un truc aussi gros que GTK (si on a besoin d'une version différente de celle de la LSB en cours, ce qui n'est pas le but) sans casser le système hote.
Je crois savoir que Google Earth marche comme ça, en fournissant son QT (il ne peut pas utiliser le QT/GPL).
Mais le but, c'est d'avoir une solution efficace (le bundle) utilisable pour des logiciels finaux sans trop de complexité. Il y a beaucoup de projets qui dépendent de GTK < 2.8, qui n'ont pas besoin des dernières versions de gtk. Dans ce cas une bundle prêt à tourner sur toute distrib compatible LSB 3.2 est tout à fait envisageable.
3) le but n'est ni de se substituer à un packaging de distribution, bien meilleure solution. C'est de pouvoir proposer une version à utiliser facilement sans casser les distribution, sans devoir attendre que la distribution ait mis à jour les paquets, et sur laquelle ont puisse demander de tester les corrections de bugs rapportés.
En gros je peux faire un AppDir que Rox considère comme un programme à lancer en utilisant comme base le wrapper d'autopackage pour positionner LD_LIBRARY_PATH. Mais il n'y a que Rox avec lequel il suffise de poser ça dans ~/App pour que ça apparaisse dans les menus. C'est la solution NextStep (et donc osX) . L'idéal serait que freedesktop en fasse une norme que Kde et Gnome (et les autres) intègrent.
On peut même imaginer que l'installeur debian fasse le tour des Appdir à l'installation/MàJour d'un logiciel pour signaler par mail à root que des bundle du même programme trainent sur le système, ça peut être une info intéressante (nettoyage tout ça). Mais ça nécessite que les bundle soient les même pour tous.
Avec autopackage/OBCLICK/klik... on multiplie les solutions, preuve qu'un réel besoin existe. Un standard de travail pour tous les bureaux, c'est le but de freedesktop. Je trouve que le bundle d'application à la NextStep manque dedans. Et que ça serait une meilleure solution que celle proposée par Ian Murdoch.