Bruno Coudoin a écrit 411 commentaires

Et comment je sais quelles sont les distributions utilisées par mes utilisateurs ?
Et si mes utilisateurs utilisent une distribution toute en chinois, je dois apprendre le chinois ?

Non, sérieusement, ce que tu proposes est un non sens total, une surchage de travail inutile. Nous on veut développer des activités enrichissantes pour les enfants, pas passer notre temps à packager pour les différentes distros.

Relis bien, ce qui est proposé c'est que chaque application livre l'ensemble des librairie dont elle à besoin, en dehors de ce qui est définit dans le LSB.

Je me permet de te faire remarquer que la situation actuelle n'est pas idéal dans la gestion des dépendance. Les distributions supposent que si ca compile avec la librairie X alors ça marche. Je suis convaincu qu'aucun test sérieux n'est réalisé pas les packageurs en ce qui concerne GCompris.

Je sais que les version RC n'ont pas leurs place mais alors comment on demande à nos utilisateurs de tester un logiciel qu'il ne pourront avoir que lorsqu'ils l'auront testé. Ou alors, c'est juste les developpeurs qui testent et la qualité et mauvaise, c'est ce qui ce passe dans le cadre du développement de GCompris.

Si tu mets des librairies système dans ton autopackage surrement mais c'est pas l'objectif. Je crois d'ailleurs que dans ce cas il garde une copie de la version ecrasée. Mais je ne tient pas autopackage comme une solution idéale, ni ceux qui le font d'ailleurs. C'est juste mieux que 'make install' pour des utilisateurs finaux.

Sinon, tu peux aussi faire un 'sudo make install' qui ecrase des lib systèmes, il n'y a pas de différence.

Tu as raison, je parlais de macosx hors propo, je voulais juste dire que sur un 'unix' on peut aussi faire des systèmes d'installation simples. Non je ne pense pas que macosx soit la panacée mais il apporte une solution élégante à ce problème.

Pour la sécurité, il faut comparer ce qui l'est. Ici on parle d'application hors distribution. Si ton application est dans ta distro, quelle est à jour, aucun problème pour toi. C'est dans le cas inverse que ça ce gate. Tu crois qu'un 'sudo make install' en terme de sécurité c'est idéal, je ne pense pas.

Pour les dépendances, c'est clair. Tous ce qui n'est pas fourni par le LSB doit être fourni par ton installation. Certe c'est loin d'être optimal en place disque et mémoire, mais au moins les gens peuvent utiliser ton logiciel !

C'est vrai que GCompris est plutot bien supporté par les distributions et c'est une bonne chose mais c'est loin d'être parfait.

D'abord le temps entre une release de GCompris et la disponibilité dans les distribution est très variable, impossible à déterminer ce qui nous éloigne de nos utilisateurs et de nos contributeurs. Pour un petit projet il nous est impossibe de maintenir 2 versions hors les distributions proposent des versions de GCompris en fonctions de leur date de sortie grosso-modo. Pour nous c'est ingérable d'un point de vu qualité. Les utilisateurs reportent des bug au packageurs qui connaissent mal le logiciel, remontent peut ou pas l'information au projet et quand ça arrive à nous on sait pas aider car la version est trop vieille ou ça dépend d'une distro qu'on a pas.

Les problème de dépendance est bien géré sous GNU/Linux mais pose un vrai problème qualitatif. Les distributions supposent en gros que si ça compile avec la librarie 1.2.3-5, forcément ça marche. Hors nous on a bien testé avec la librairie 1.2.3-4 mais jamais avec la -5. C'est compatible, ça compile mais personne n'a jamais testé avec. Souvent ça marche mais parfois ce n'est pas le cas. Lorsque les développeurs mettent des require sur certaines librairies, le packageurs les modifient pour que ça compile mais comme il ne teste pas, il ne voient pas que dans certains cas ça marche pas.

Certains se débrouillent^W bidouillent très bien aujourd'hui (oracle, google, nvidia).

Oui on peut y arriver aujourd'hui mais c'est pas simple, ni pour les developpeurs, les mainteneurs et les utilisateurs.

Le problème des DLL vient en grande partie du fait que les logiciels installent des DLL dans le répertoire système partagé, influant sur l'intégrité du système.

Il n'est pas prévu je suspose de permettre ou d'encourager cette pratique mais par contre, bien sur, il faut que les logiciels fournissent les librairies dont ils ont besoin et qui ne sont pas intégrées dans le LSB.

Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle

Ramener le problème à l'aspect libre/propriétaire est une erreur. Ce sont 2 problèmes bien distinct. Je fais du logiciel Libre ET je désire que mes utilisateurs puissent l'installer simplement, quelque soit leur distribution.

Qui te parle de brider quoi que ce soit !

En quoi rendre l'installation de logiciel simple pour certains utilisateurs t'empèche de faire quoi que ce soit avec ton système ?

Aujourd'hui, avec GNU/Linux, ce sont les utilisateurs qui sont bridés. On leur enlève la liberté d'installer des logiciels et tant qu'on ne leur rendra pas cette liberté, il n'y a aucune chance de progresser dans le grand public.

Qui te parle de brider quoi que ce soit !

En quoi rendre l'installation de logiciel simple pour certains utilisateurs t'empèche de faire quoi que ce soit avec ton système ?

Aujourd'hui, avec GNU/Linux, ce sont les utilisateurs qui sont bridés. On leur enlève la liberté d'installer des logiciels et tant qu'on ne leur rendra pas cette liberté, il n'y a aucune chance de progresser dans le grand public.

Si je ne comprend bien, cet outil prend en entrée des "Debian source packages", pas des sources packages fournis directement pas le projet. Si tu préfères le travaille de packaging propre à la distribution est déjà commencé, l'utilisateur peut alors le terminer. Cela ne résoud en rien le problème.

Commen tu fais pour livrer à tes utilisateurs GNU/Linux un programme qu'ils puissent installer simplement, quelque soit leur distribution.

Euh, t'a entendu parler de macosx ?

Ils font en sorte que l'installation des logiciels soit simple pour les utilisateurs et c'est le cas. Et je n'ai pas le sentiment que cela les ait emprêché d'innover.

Donc, oui, il sauf une base commune à tous les GNU/Linux et le LSB est un bon candidat. Il manque ensuite un système simple pour l'installation des logiciels indépendant de la distribution ce que nous n'avons pas.

Tu dis que le problème est faux mais tu proposes une autre solution. Faut savoir !

Ta solution ne marchera pas. Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ? Et des raissons que ça marche pas la compilation, c'est pas ça qui manque... (Déjà dit plus haut mais bon)

En plus ton système pre-suppose que tout le monde à un accés haut-débit. Quid de la distribution de logiciel en paquet binaire dans les magazine. Ce serait pourtant pratique pour beaucoup.

Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?
Et des raissons que ça marche pas la compilation, c'est pas ça qui manque...

La réponse en anglais sur le site de autopackage http://autopackage.org/faq.html#2_3

En gros, ça marche pour certaines distro, pas pour d'autres. Ils ont dont choisi de se fixer sur /usr ca c'est ce qui marche le mieux.

Autopackage est loin d'être idéal c'est clair mais le probléme n'est pas autopackage contre rpm/dpkg mais autopackage contre make install.

Si ton logiciel est dans ta distro très bien, c'est l'idéal mais quand il n'y est pas tu fais quoi: make install.

Et 'make install' c'est aussi: pas de vérification des signatures, pas de systémes de gestion des mises à jours, et ç'est relativement fragile et décentralisé.

Mais aussi et surtout: inaccessible pour un utilisateur final.

Ben voyons, on parle de grand public ici. Un compilateur n'a pas à être installé sur un PC grand public.

En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball. Sur windows, sur mac, c'est facile mais sur windows tu fais comment. Pour un petit projet c'est très compliqué que de fournir un paquet binaire ne serait-ce que pour les 5 distros les plus courantes.

On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !

"En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers."

Hum, c'est pas si évident malheureusement. Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr donc autopackage est obligé de se mettre dans /usr au milieu des logiciels de ta distro.

Le problème vient principalement des menus et des type mime. Il y a des répertoires centralisés pour eux donc obligation de les respecter.

Mais oui clairement autopackage n'est pas la panacée mais c'est mieux pour un projet de livrer ça que juste un tarball. Au moins un utilisateur lambda à une chance de pouvoir utiliser ton logiciel.

Il existe déjà un mécanisme standardisé par le freedesktop pour qu'une application précise ou son menu doit être placé. Les différentes catégorie sont déjà définie. Je ne vois pas trop la valeur du packaging de la distro la-dessus.

C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !

Le problème c'est qu'en embétant les logiciels propriètaire, on rend aussi la vie difficile aux utilisateurs de Logiciel Libres.

Tu prend un logiciel, genre un jeu libre annoncé ici même. Il faut combien de temps avant de l'avoir dans les distros ? Il se passe des mois, voir des années.

Donc bien sur tu t'en fou, probablement que tu compiles mais ici on parle bien d'utilisateur personnels qui n'ont ni l'envie, ni les compétences pour compiler.

Donc contrairement à ce qu'on pense généralement, ce problème d'installation de logiciel sur GNU/Linux concerne aussi les Logiciels Libres.

Oui, sauf que ce que l'on demande c'est la compatibilité au niveau source et un format de distribution binaire. Si tu penses que les paquets binaire c'est le mal, n'utilise pas rpm ou deb. Ce qu'on demande c'est pas compliqué, on veut des paquets binaires multi-distro.

Hehe, Pire que tout, personne n'a jamais réussi à faire un paquet GCompris pour une fedora core 4 !

Pour les problème technique, je ne suis pas en expert. Si tu es a compris pourquoi c'est important, c'est déjà une bonne chose, il y a des gens très compétents dans le monde Linux qui j'en suis sur vont prendre ce probleme à bras le corps et venir avec des solutions.

Ce qui m'enerve le plus ce que nous nous persuadons tous que la situation actuelle est optimale et tolérable pour les utilisateurs grand public.

Oui, c'est sûr que GCompris est une application Java pour windows. Je parles en toute connaissance de cause car je suis confronté au problème. En tant que développeur, j'ai envie juste que les utilisateurs puisse installer simplement le logiciel sur lequel je travaille, tout simplement.