Raphaël SurcouF a écrit 2609 commentaires

Oui mais Loki a fait néanmoins faillite. Qui assure le suivi et le développement de cet outil à présent ? Est-il libre ?

Et si debian a mis en place backports.org, si ubuntu a eu tant de succès, si quasiment tous les projets libres fournissent des binaires, c'est bien pour répondre à un besoin. Et ce besoin, je trouve que tu en sous-estimes l'importance.

Je n'appelerais pas vraiment cela une besoin mais une demande.
Les utilisateurs qui demandent toujours la toute dernière version des logiciels ne savent pas toujours pourquoi ils veulent la toute dernière. Si encore, ils arrivaient à dire pour quelle raison ils ont absolument besoin de la toute dernière version, je ne dis pas. Mais force est de constater qu'ils ne le savent pas toujours eux-mêmes.
Petite précision : ce n'est pas le projet Debian qui a mis en place backports.org mais des utilisateurs et quelques développeurs Debian. De même pour Ubuntu, les paquets ne provenant pas de main ne sont pas officiellement supportés par Canonical. Les utilisateurs utilisent donc ces paquets binaires à leurs risques et périls. Dans le monde commercial, ils ne pourraient pas se retourner contre l'éditeur dans un pareil cas.

Si tous les projets libres, y compris les nouveaux et quelque soit leur notériété, étaient sûrs que debian/fedora/mandr* sortiront dans les trois mois une nouvelle version avec leur dernière mouture, la question n'aurait pas tant d'importance.

S'ils sont capables de développer des applications, pourquoi attendent-ils donc qu'un tiers veuille bien faire un paquet binaire pour la distribution X ? Pourquoi ne prennent-ils pas le temps de faire eux-même un paquet binaire pour Debian, Ubuntu, Fedora ou Mandriva (qui sont assez représentative) en fonction de la distribution qu'ils utilisent déjà, quitte à le proposer dans un premier temps hors distribution. Sous Ubuntu/Gnome, il existe un logiciel permettant d'installer un paquet deb en double-cliquant simplement dessus. Il gagnerait à être perfectionné (notamment en téléchargeant les dépendances manquantes si possible via APT).

Alors non je ne suis pas d'accord avec toi. Je trouve fondamental pour linux qu'une solution de mise à disposition de binaire de type unzip and click, ou setup, qui ait une petite chance de marcher chez beaucoup de monde c'est essentiel. Et plus pour les projets libres que pour les propriétaires. Que l'absence ne gène de toutes façon pas beaucoup (java, realplayer, flash, nvidia...). Oui c'est un risque pour la sécurité.

Force est de constater que les solutions autopackage, klik, etc. sont encore loin d'être aussi populaires. On mettra ça sur le compte de la possible jeunesse des dits projets. Mais visiblement, ces projets sont surtout là pour permettre à des logiciels propriétaires de prospérer sous Linux et tu ne peux pas demander aux utilisateurs de Logiciels Libres de souhaiter une telle chose. Il ne faut pas oublier que la première liberté accordée aux utilisateurs de Logiciels Libres, c'est précisément de ne plus dépendre du bon vouloir de l'éditeur concernant le développement du logiciel : le libre accès aux sources représente ce moyen.

Ce que j'aimerai c'est que tu te mette à la place de ceux qui ont passé des années à développer des logiciels et qui sont déçu par le modèle de distribution de GNU/Linux. Ce n'est pas un problème spécifique à GCompris, ce , n'est pas spécifique au domaine du jeu, mais à l'ensemble des logiciels libre ou pas qui désirent faire une version pour notre plate-forme.

Je ne peux pas me mettre à votre place, en effet mais ce mode de distribution ne date pas d'hier. J'ai davantage l'impression que les seuls développeurs vraiment intéressé par une telle main-mise sur la distribution sont/seront également davantage porté sur du code propriétaire sinon, c'est un problème d'égo (voir le cas DJB).

Tu écoutes les besoins de TES utilisateurs, c'est très bien et même plutôt une bonne chose mais essaie de comprendre que les autres utilisateurs ne sont pas forcément du même avis et j'en fais également partie. Nous sommes tous des utilisateurs de Logiciels Libres.

Pour finir, ton problème sera sans doute résolu par un compromis : l'intégration des outils comme autopackage, etc. sous forme de paquets binaires pour les distributions afin d'éviter qu'il ne fasse n'importe quoi (ainsi, la distribution pourra ajouter les chemins nécessaires aux logiciels, ce qu'autopackage ne sait pas faire par défaut). Je trouverais ça déplorable mais ça aura au moins le mérite de contenter certaines personnes.

Je ne vois pas ce qu'un système plus "user-friendly" pour installer des logiciels dans /usr/local facilement apporterait aux utilisateurs.
Ce n'est pas parce que tu viens de publier ta toute dernière version estampilée "stable" parce que son état actuel te convient et que tu estimes avoir suffisament passé de temps pour corriger les bogues qu'elle sera complètement exempte de bogues ultérieurs (simplement parce que les utilisateurs utilisent d'autres distributions que toi, qu'ils utilisent un matériel forcément différent). Je ne pense pas qu'il appartienne à de charmants bambins de 5 ans d'essuyer les plâtres de ces éventuels bogues. Si c'est des testeurs dont tu as besoin, dis-le clairement mais ne viens pas nous que c'est de la faute au mode actuel de distribution (qui est davantage un garde-fou pour les utilisateurs, justement).

Si la v3 a besoin de droit root, c'est que son installation requiert davantage d'implications avec la distribution cible. Ubuntu ne va pas changer ses méthodes pour une seule application : c'est aux utilisateurs d'Ubuntu (au sens large : je pense surtout à ceux qui "l'administrent" au sein de l'école) de faire le nécessaire pour que ça fonctionne malgré tout, quitte à précéder l'exécution du script par la commande sudo. S'ils n'ont pas connaissance de ce mode de fonctionnement particulier, c'est qu'ils ont un problème.

En ce qui concerne les paquets prévus pour Debian, il n'a jamais été dit que l'installation de tels paquets sur une Ubuntu était conseillé mais qu'au contraire, cela pouvait PARFOIS fonctionner mais en aucun cas être généralisable. Il devrait néanmoins être facile de reconstruire les sources du paquet pour Ubuntu, notamment grâce à pbuilder[1]. Peux-tu me dire quel est le problème exact avec le paquet d'ofset ?

Pour finir, je suis ravi de voir qu'Ubuntu a été choisi pour leur école mais je me demande pourquoi ils n'ont pas pris plutôt Edubuntu, vu l'usage qu'il en est fait (par ignorance ?).

[1]: http://doc.ubuntu-fr.org/applications/pbuilder

Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.

En quoi est-ce un problème ? Les cycles de publications des versions stables des bibliothèques sont plutôt longs, surtout pour les versions mineures et majeures : pour les versions de patchs, je ne pense pas que tu ai besoin d'être aussi à jour (et ton co-développeur l'a déjà dit, sauf erreur). En outre, les développeurs de bibliothèques maintennent généralement la version précédente même après que la nouvelle branche ait débuté, tout comme Linux.

Je trouve domage que tu tapes de la sorte sur les développeurs sans comprendre aussi leur difficulté. Il sont dans l'incapacité de cibler une version spécifique de librairie car personne ne défini une référence commune.

Les développeurs n'ont pas besoin d'une référence commune, ils ont simplement besoin d'ABI et API qui correspondent à leurs besoins de programmation. S'ils ne savent plus à quelles bibliothèques se vouer, c'est qu'ils ont mal défini leurs besoins.

Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux. Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.

Non, c'est faux. La plate-forme de développement de tout développeur, à moins qu'il ne soit parti d'une base de LFS, est fatalement une des nombreuses distributions qui existent déjà.
En outre, à moins qu'il ne se contruise un environnement protégé ("chroot", "jail", ce qu'il veut) pour faire son développement, il devra forcément composer avec les bibliothèques fournies par la distribution ou les compiler lui-même (ce qui rentre un peu dans le cas de l'environnement "protégé"). Et si son application a besoin d'une bibliothèque qui n'est pas encore disponible dans la distribution, il appartiendra aux responsables de paquets volontaires de faire le nécessaire pour combler le manque. Or : si ton application est bien censée fonctionner avec la version Y de bilbliothèque X, je ne vois pas pourquoi ils ne parviendraient pas à créer le paquet binaire eux-mêmes.
J'ai de plus en plus la nette impression que tu ne veux/peux pas nous dire quel est ton véritable problème et but dans cette histoire, comme si tu avais des clients un peu exigeants.

Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.

Si ton logiciel plante avec une version particulière de la distribution, ce n'est pas la faute du mode actuel de distribution des logiciels libres mais plutôt entre GCompris et SDL. Sous Debian sid, c'est encore la 1.2.6 : tu devrais peut-être te demander pourquoi la 1.2.7 n'y est pas encore...

La seule est unique solution pour avoir des logiciels stable sur une plate-forme stable c'est de ne pas tout mélanger comme nous le faisons actuellement. Il nous faut un coeur de librairies les plus courantes, bien définies et que les projets peuvent cibler. En dehors de cela, il faut que chaque projet livre ses librairies car il est sûr que son projet marche avec. Certe c'est pas optimisé et on ne va pas faire ça pour tous les logiciels mais ça doit être une option possible et simple à faire, à la fois pour les développeurs mais aussi pour les utilisateurs. Bien sûr on a besoin d'un bonne intégration dans la distro.

Il y a un détail qui me choque dans ce paragraphe : à quoi servira-t-il d'avoir des distributions si la base LSB suffit amplement aux développeurs ? Et qu'adviendra-t-il le jour où les développeurs auront besoin d'une version à jour de la bibliothèque X parce qu'elle implément la toute nouvelle fonctionnalité Y ? Crois-tu qu'ils feront en sorte que la base LSB soit mise à jour ? On peut en douter et combien même serait-ce le cas, il est bien possible que la base LSB refuse de mettre à jour la dite bibliothèque pour des raisons de stabilité de la dite base qui sert de référence : chose que tu demandes aussi...
Je souhaite bien du plaisir à Ian Murdock.

Puis bon, effectivement, les bonnes pratiques de gestion de version de libs existent, faut-il encore que la libification ait été faite correctement par les développeurs (gecko cause quelques petits soucis par exemple, ceci expliquant que le dernier firefox 2.0 n'est pas packagé par pas mal de distribs en backport vu que cela casse epiphany, galeon, yelp et d'autres trucs...).

Lesquelles ?

Les libertés des utilisateurs s'arrêtent là où commencent celles des développeurs, sachant que ce sont ces derniers, via les licences libres, qui accordent des droits et libertés sur les logiciels libres qu'ils développent.

Mais le reste de la distribution n'est pas mis en danger, au sens ou un bug dans une libpng fournie avec une bundle firefox 5 ne mettrait pas en danger le firefox 3 de la distribution ?

Une faille de sécurité, quellequ'elle soit, mettra en danger l'intégrité de tout le système. Il est illusoire de croire que, parce qu'on a "cantonné" (parce que ce n'est même un chroot) l'application avec une ou deux variables d'environnement pour éviter les conflits entre versions concurrentes.

Je me demande si le "problème" n'est pas uniquement lié aux jeux libres.
Je ne pense pas, non. Pas seulement en tout cas. inkscape propose un autopackage. Oinstall vient du côté de chez rox. klik semble venir de kde, à mois que le k ne m'induise en erreur. Ce sont des solutions qui répondent à cette problèmatique. Sans venir des jeux.

Inkscape est le seul contre-exemple. La plupart des logiciels cités ici sont des jeux.
Quant à Klik, le K porte effectivement à confusion : ce projet n'a rien à voir avec le projet KDE. Quand on voit les logiciels présentés sur le page de garde du projet Klik, on peut se demander s'il ne s'agit pas là, en fait, un moyen pour que les éditeurs commerciaux puissent avoir leurs logiciels propriétaires (Opera, Skype, RealOnePlayer) installés sous Linux. Quant aux projets Google, pourquoi ne sont-ils pas encore packagés dans les distributions majeures s'ils sont "free" (comme Picaza) ? Sans doute parce la licence l'interdit (le logiciel est donc moins libres). Ou est-ce parce que la demande est devenue moindre parce que les utilisateurs peuvent l'installer sans "efforts" ?
Bientôt, si on continue dans cette voie, il n'y aura plus besoin de migrer de Windows à Linux parce que ce sera la même pagaille.

J'ai l'impression que les développeurs de ces jeux attaquent le mode de distribution actuel uniquement parce que leurs jeux ne sont pas assez populaires au lieu de chercher s'il n'y aurait pas une autre raison. Quand on voit la diversité qu'il existe au niveau des jeux avec chacun sa propre API 3D ou peu s'en faut, il vaudrait mieux se pencher sur cette question avant de demander aux autres de mettre un peu d'ordre dans la cathédrale.
eu... ils utilisent pas tous OpenGL, les jeux 3D libres? Bon j'avoue, j'y connais rien. Ma nvidia/ppc ne fait pas la 3D, je connais assez peu ce domaine.

Les jeux n'utilisent pas que la 3D et si c'est le cas, il ne faudrait pas non plus que ça dépende de nvidia (les problèmes pour avoir un support 3D correct sous Linux sont davantage la cause des problèmes de "démocratisation" de Linux que le mode de distribution des logiciels au sein des distributions) ou d'ati.

Non, le besoin est plus précis. Quand Pysycache a été anoncé ici, j'ai voulu le tester sous linux. La v2 marchait directement en dézippant et en lançant le fichier python. Dézippé et click. Et pouvoir l'utiliser sans attendre que debian l'intègre (ou que quelqu'un propose des deb, comme c'est le cas maintenant).

Et quelle version de Psysycache (encore un jeu) utilises-tu actuellement ?

En ouvrant le menu contextuel, tu regardes parmi les propriétés. L'onglet "Ouvrir avec" te permettra de sélectionner l'application préférentielle.

Non. C'est de ne pas pouvoir le faire. Si on était une douzaine...
Et que ce ne soit pas fait correctement par les distributions. Comme ils ne remontent pas les bugs (ou rarement) on a l'impression de faire un logiciel parfait. Sans compter que j'ai du un jour engueuler le developpeur ubuntu pour que ça ne soit pas une version cvs dans dapper. S'il nous en avait parlé on aurait pu l'aider. Je m'en suis rendu compte par hasard.

Tu rapportes là un problème de communication entre responsables et développeurs. Ce genre peut arriver, c'est humain après tout.
Je commence à mieux comprendre d'où vient cette rancoeur.

Alors il ne faut pas faire un support sur plus de 6 mois. Il faut que la mise à jour soit automatique comme pour les MàJ de sécurité.

Le support est nécessaire parce que les utilisateurs le demandent. Tout le monde n'a pas non plus envie de changer de versions tous les 6 mois ni tous les ans. Il n'y a pas que les particuliers pour utiliser Linux. Les mises à jour de sécurité sont différentes des mises à jour fonctionnelles. Quand on publie une version stable, on assure à l'utilisateur d'avoir réalisé des tests préliminaires pendant une période assez longue pour éviter les problèmes évidents. Les mises à jour de sécurité n'ont pas pour vocation de monter en version un logiciel mais uniquement de corriger le code responsable de la faille à l'aide d'un patch. Ce n'est pas un mode de fonctionnement cantonné aux Logiciels Libres.

Plus sérieusement, tu as un raisonnement franchement binaire: on change tout, ou on change rien.

Ce raisonnement binaire vient du système de bibliothèques dynamique, pas de moi. Comment veux-tu mettre à jour GTK+ et assurer la stabilité de la distribution et des applications qui en dépendent si tu n'y prêtes pas attention ? Je dirais plutôt que vous (les développeurs de GCompris) avaient une vision plutôt réduite des problèmes de cohabitation des logiciels sur un système. Une vision propre aux développeurs, centralisée sur leur projet à eux.

Un peu de granularité, je trouve que ça serait bien. Par exemple changer juste les logiciels qui fournissent un .desktop (et qui restent compatible) tous les 6 mois, et ne changer la base que tous les deux ans, ça me conviendrait très bien.

Oui mais au risque de me répéter, que fais-tu des dépendances des "logiciels fournissant des .desktop" ? Que fais-tu des logiciels tiers ayant implémenté la toute nouvelle fonctionnalité de la dernière version de GTK+ ? Il ne pourra pas le faire si GTK+ reste cantonner à la version de la distribution. La prétendue compatibilité binaire vantée par Murdock sera une atteinte à la l'innovation logicielle.

Firefox/Openoffice/gcompris/inkscape pourraient surement tourner sur sarge dans leur dernière version. C'est FF 1.04; OOo 1..1.3, gcompris 6.5.2 et inkscape 0.41 qui sont dans sarge. Je n'ai pas besoin des nouvelles fonctionnalité de sarge le nouvel installeur m'indiffère, le gtk de sarge me convient, son gnome me va aussi. Ce sont les applications sur le bureau dont j'ai le plus besoin qu'elle soient à peu près à jour.
Mais c'est tout ou rien. Je suis donc en etch avec les inconvénients qui vont avec.

Le problème, c'est que le GTK+ de sarge ne conviendrait certainement pas pour les dernières versions des logiciels que tu as mentionné. Donc, si c'est pour fournir les bibliothèques en sus, soit tu compiles en statiques, soit tu fais du cygwin pour Linux et tu crées donc une distribution par dessus la distribution. De là à créer une nouvelle distribution, il n'y a plus qu'un pas...
Pour continuer dans ton raisonnement, si tu n'as pas besoin des dernières fonctionnalités : tu n'as pas besoin des dernières versions.
Le problème ne se pose donc pas.

Et le nombre de projets pour pallier à ça (Murdoch, autopackage, klik, 0install) montre quand même que c'est un problème loin d'être anodin.

Des projets de logiciels libres, il en existe des milliers. La quantité de projets n'est pas forcément synonyme de grands besoins mais surtout d'un manque total de cohésions entre les divers projets.

Il faudrait aussi que certains développeurs sortent un peu plus souvent de leurs tours d'Ivoire.

>ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus

Qui parle d'un outil graphique ? Ce que je veux dire, c'est que l'installation d'un serveur aussi critique qu'un serveur de mail est loin d'être donné à tout le monde. La quantité de spam relayé en est la meilleure preuve. Le pire étant que beaucoup d'admins croient savoir le faire, alors que leur trucs sont de vrais passoires, mais ont-ils vraiment le choix ?

Par outil puissant, j'entends un outil (peu importe sa forme) permettant d'intégrer une solution de mail dans sa boite sans être un gourou. Celà ne veux pas forcement dire graphique. Mais celà veux dire avec des tests, avec une analyse systématique des logs, avec la possibilité de déclarer l'existant, obligations en terme de backup ...

Tu sais bien que ce n'est pas parcequ'un serveur marche, qu'il est correctement configuré.

Alors pour reprendre l'exemple des serveurs de mail, tu peux toujours supporter exim, sendmail, postfix, qmail, courier, cyrus, teapop, uw ...
Ceci dit faire des choix et les pousser le plus loin possible, c'est pas mal non plus. En ce sans pour revenir au sujet de départ, un systeme de paquet universel, permettrait aux distros de se concentrer sur quelques paquets tout en garantissant à l'utilisateur la diversité à laquelle il peut légitimement aspirer. Je ne donnais que quelques exemples de choses qui à mon sens auraient besoin d'être faites et qui ne le sont pas.

L'idée générale c'est faire moins de paquets pour faire d'autres choses. Merci de me répondre la dessus.

Puisque tu parlais d'un outil "desktop" donc graphique, j'ai donc extrapolé le besoin. Pour répondre à tes questions, le problème est qu'il existe des besoins bien différents et de nombreux outils pour réaliser les mêmes besoins si bien qu'il n'y a pas de solutions miracle. Toutefois, il est possible de créer des paquets pour disposer d'une configuration particulière à partir des paquets de la distribution initiale. Rien n'empêche de le faire et de créer une sous-distribution de Debian (par exemple) créant de toutes pièces l'outil dont tu as besoin. Ces solutions existent déjà : des solutions commerciales comme des solutions libres (je pense notamment à l'exemple d'OMA). N'oublie pas que les logiciels libres répondent à des besoins avant-tout égoïstes : ceux des développeurs/utilisateurs.
Les distributions créent des paquets, c'est déjà un énorme pas pour pouvoir utiliser ces logiciels sans avoir à les compiler. D'autres part, ce n'est pas à la distribution de te dire qu'il faudrait utiliser une partition XFS pour stocker ton /var/spool/cyrus. En général, les entreprises qui veulent utiliser et intégrer de tels logiciels libres sans en avoir les compétences en interne font plutôt appel à une société externe : ainsi, si ça ne marche pas, ils peuvent se "retourner" contre le prestataire/fournisseur.

>il vaudrait mieux prendre le temps d'éduquer ses enfants

Il vaudrait mieux éviter ce genre de réflexions qui peuvent être blessantes.

Ce qu'il fallait comprendre dans cette phrase, au lieu de monter de suite sur tes grands chevaux, c'est qu'on ne doit pas se reposer entièrement sur un outil pour espérer éduquer ses enfants. D'où mon image du casque pour un enfant. Il y a aussi des cache-prises ou des protèges-coin mais il faut bien que l'enfant apprenne que tomber, ça fait mal, que l'électricité c'est dangereux, etc.
Donc, oui, avoir un filtre parental, c'est bien gentil mais une fois que l'enfant ira utiliser un ordinateur dans un autre lieu (par exemple, chez sa tante puisqu'elle sait qu'elle peut utiliser les ordinateurs) et là, paf, elle tombera sur un site de cul, faute de filtre.
C'est le rôle des parents d'accompagner l'enfant en évitant au mieux le pire. Mais on ne peut pas se reposer uniquement sur un artifice technique.

Ma fille à 6 ans, elle apprends à écrire et à rechercher sur google.
Hiers matin elle se lève vers 8h. J'étais déjà parti au boulot et ma femme dormait encore.

Là, je suis désolé mais je rejoins l'avis de fleny68 : comment se fait-il que, sous prétexte d'autonomie, ta fille puisse allumer l'ordinateur familial alors que sa mère dort toujours ? Tu lui as interdit de regarder la télé avec pas mal de restrictions mais pas l'ordinateur, c'est plutôt incohérent... Autant la télévision est un monde plutôt aseptisé car ils évitent de choquer les enfants (à 7h du mat, y a plein de dessins animés, par exemple). L'Internet est un reflet numérique du monde réel : tout y est même ce que nous édulcorons d'habitude et que ça nous plaise ou non. Je ne vois pas donc pas pourquoi tu lui interdis la télé notamment la pub... Après tout, il y en aussi sur Internet.

Elle file sur un ordi, lance firefox, pour retrouver le jeu en flash avec lequel elle avait joué la veille et tombe sur un site de cul. C'est pas un drame, mais je trouve que c'est inapproprié.

Et quand elle va à l'école et qu'elle voit une publicité Aubade, n'est pas inapprorprié ? Tu ne pourras pas toujours être là pour lui bander les yeux.

Quand on éduque ses enfants, on se rends justement compte a quel point l'image qu'ils ont de la sexualité est fragile et dévie facilement vers des idées fausses ou fantasmagoriques. Alors oui que ma fille de 6 ans tombe sur un site de cul, ça me fait profondement ch*.

Comme leur apprendre que les garçons naissent dans les choux et les filles dans les roses parce qu'on élude toujours la question fatidique ?

Si devenir m'a bien appris une chose, c'est qu'il ne faut pas avoir de certitudes à ce sujet. Rien ne sera comme tu le pensais et pourtant, tu trouveras ça merveilleux de voir ton bout de chou essayer de marcher ou de dire ses premières syllables.
On ne sait jamais ce qu'on fera vraiment sans être au pied du mur.

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.

Pourquoi mais le LSB devra alors pouvoir évoluer régulièrement sans quoi aucune distribution n'aura envie de le respecter.

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.

Le problème se poserait en ces points : pourquoi est-ce que l'utilisateur final continuerait à utiliser une distribution particulière s'il lui suffit d'en disposer d'une seule et d'installer les nouvelles versions de ses logiciels favoris via le système de bundle ?
Le risque de dérive n'est pas négligeable à mon sens et les outils de bundle risque de devenir une distribution à part entière à l'image de Cygwin pour Windows. Charge ensuite aux mainteneurs de fournir des versions à jour pour les failles de sécurité. La distribution pourra être facilement tenue à jour mais quid de la bibliothèque png fournie avec les bundle ?

Les problèmes de mise à jour de sécurité ou de mise à jour tout court (bugfix notamment). Au départ, les bibliothèques dynamiques ont été mises en place pour gagner de la place. Elles ont été conserver pour faciliter les mises à jour des différentes parties qui compose un système.
Je me demande si le "problème" n'est pas uniquement lié aux jeux libres. J'ai l'impression que les développeurs de ces jeux attaquent le mode de distribution actuel uniquement parce que leurs jeux ne sont pas assez populaires au lieu de chercher s'il n'y aurait pas une autre raison. Quand on voit la diversité qu'il existe au niveau des jeux avec chacun sa propre API 3D ou peu s'en faut, il vaudrait mieux se pencher sur cette question avant de demander aux autres de mettre un peu d'ordre dans la cathédrale.
Tu veux que des tests soient réalisés ? Commence déjà par mettre en place des tests de régressions (autre sujet de discussion à propos des logiciels libres) et réunis autour de toi des utilisateurs relativement compétents et qui sont prêts à tester le logiciel. Mais il n'y a pas guère de solutions miracle et je refuse que ce soit les enfants de 3 à 10 ans (pour GCompris) qui en soient pour leur frais.

Non. Ubuntu mets tout à jour tous les 6 mois, et en plus il "supporte" sa distrib au moins 18 mois. Voire 5 ans pour Dapper.

Ce qui fait que dans 4 ans, Ubuntu continuera à supporter gcompris 7.2. Mais comme ils n'ont pas l'air de faire grand chose pour le fixer eux-même, et bien pendant 4 ans les utilisateurs de Dapper gardent les mêmes problèmes.

Ce qui gonfle un peu les dev GCompris, comme idée.

Donc, si j'interprète correctement : ce qui "gonfle" les développeurs de GCompris, c'est de devoir supporter les anciennes versions.
Désolé mais dans les véritables environnements, tu auras toujours des utilisateurs qui utiliseront l'ancienne version et à qui la réponse "- faut passer à la dernière version" ne conviendra pas. GCompris est sans aucun doute un cas particulier mais votre mode de fonctionnement désiré ne peut pas s'appliquer à tous les logiciels.

A moins qu'une mise à jour Dapper change la version de GCompris, mais justement non, c'est contraire à la politique. Que des patchs.

Est-ce que cela signifierait que votre développement est incapable de corriger les bogues des versions précédentes en publiant les versions ultérieures ? Je ne crois pas. En outre, il existe tout de même des dépôts de rétro-portage, bien que non disponibles par défaut qui permettent d'avoir les dernières versions, au pire.

Imagine que tous les 6 mois, les apllications utilsateurs de Dapper soient mises à jour (celles qui marchent avec le gtk/qt de dapper). Firefox, GCompris, OpenOffice, Tuxpaint backportés officiellement dans Dapper tous les 6 mois. C'est ça que je voulais dire.

Tous les 6 mois, une nouvelle version de la distribution est publiée. Il suffit simplement pour l'utilisateur de changer de version. Après tout, il n'y a pas que GCompris dans la vie.

Je pense qu'il y a un problème entre votre désir de voir votre logiciel utilisé et testé par des utilisateurs. On en revient à ceci : plutôt que vous dispersez à vouloir que les 200 et quelques distributions soient toutes supportées, il n'y a guère que deux formats binaires importants (Debian et RPM), aussi il ne faut pas non plus trop attendre que quelqu'un d'autre que vous fasse un paquet binaire pour une distribution particulière (notamment FC4 : s'ils ont des problème pour le compiler, ils auront du mal à en produire des paquets).
Par contre, je ne comprends pas ce que tu entends par "Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.". En quoi est-ce des paquets différents ? D'ailleurs, tu as oublié de mentionner cette option : utiliser une source tierce pour disposer de la nouvelle version prévue pour SA distribution et si vous n'êtes pas en mesure pour les produire, il faut bien qu'un "gentil" contributeur s'en charge.

Quel moteur d'Apache2 utilises-tu ?
En outre, peux-tu voir dans tes logs si tu n'y vois rien d'étrange ?

Il faudrait prendre le raisonnement inverse : personne ne peut forcer les utilisateurs à utiliser Linux. De même, personne ne peut obliger les divers acteurs du Logiciel Libre a utiliser un pseudo-standard.
Les standards s'adoptent parce qu'ils s'inscrivent dans une certaine logique pour les utilisateurs (au sens large) mais on ne les impose pas (à moins d'être en position de monopole).
Qu'Ian Murdock planche donc sur son problème et on verra bien ce qu'il en sortira mais à mon humble avis, ce sera sans doute sans suite.

Il faudrait surtout arrêter de vouloir à tout prix tout mélanger.
Les postes de travail, l'ordinateur personnel et les serveurs ont besoin de systèmes dont les besoins en terme logiciels sont totalement différents et parfois complémentaires.
Ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus.
Quant au poste de travail, il existe déjà des distributions qui se sont faits une spécialité en ne proposant qu'une voire deux maximum logiciels par type de logiciels (Ubuntu pour ne pas la citer). Les environnements comme Gnome et sans doute KDE proposent déjà des la définition de profils d'utilisateurs (avec sabayon pour Gnome).
Pour le contrôle parental, pour l'heure, il n'y a guère de solution concrète et graphique mais à la rigueur, il vaudrait mieux prendre le temps d'éduquer ses enfants : c'est un peu comme vouloir mettre un casque à un bébé de 12 mois qui apprend à marcher. Quand il n'aura plus son casque, il n'aura jamais eu la conscience du danger : oui, tomber, ça fait mal alors il faut faire attention. Ça s'apprend, ce n'est pas inné.
La solution "universelle" d'installation n'existe pas et encore moins au pays de Microsoft, il n'y a qu'à voir le nombre d'installateurs utilisables et différents pour s'en convaincre.

Puisque Windows représente toujours plus de 90% des utilisateurs potentiels, tu n'as qu'à fournir qu'un paquet msi pour eux et puis c'est tout.
Dit autrement, sous prétexte de ne pas pouvoir fournir Gcompris à 100% des utilisateurs, devrais-tu t'interdire de le fournir à 95% d'entre-eux ?
Je n'arrive pas à cerner ton problème finalement. Quels peuvent donc être ces utilisateurs si importants à tes yeux ?

Je suis désolé mais installer un logiciel dont les dépendances en matière de bubliothèques peuvent à un moment ou à un autre interférer avec celles du système (ou vice-versa), c'est plus dangereux et vicieux que l'éventualité de toucher aux systèmes de paquets.
Il ne faut pas oublier que les systèmes dynamiques que sont les distributions sont des systèmes vivants et non pas statiques.
Il faudra donc que les tiers se contentent de fournir des binaires statiques ou rien. Il n'y a pas de solutions simples à ce faux-problème.

Et ça nécessite de pouvoir proposer aux utilisateurs des distributions une installation hors circuit officiel de la distribution facilement.

Il n'y a aucun problème pour proposer un projet se basant sur Debian.
Debian est devenue de fait une méta-distribution depuis longtemps et il est justement du rôle de distributions spécialisées de sélectionner les logiciels pertinents en fonction de l'usage qui est prévu.
Un développeur n'aura pas les mêmes besoins qu'un administrateur système, un webmester, un infographiste ou encore un joueur.
Hors, le projet Debian n'est pas opposé du tout aux projets s'appuyant sur sa riche logithèque : les exemples ne manquent pas.

Ton "Debian core" et ton "Debian apps", pour ma part, ça existe déjà : c'est simplement Debian et Ubuntu. Tu parles de LSB et les logiciels serveurs importants : mais quels sont-ils ? Apache, OpenSSH ?
Tout ce que tu proposes (dont le "Debian Core" est très proche du DCC d'Ian Murdock) est déjà proposé par Ubuntu. La compatibilité binaire reste un mythe là où la compatibilité source fonctionne.

Alors y serait peut-être temps que toutes les distributions aient une base suffisante de librairies équivalentes qui permettent de diffuser des programmes sous forme binaire, avec pourquoi pas un installateur, qui ira coller le programme dans /usr/local/ et qui enregistrera les informations de désinstallation grâve à la fameuse API...

Si tu tiens à bloquer l'ABI des bibliothèques, libre à toi mais tu m'expliqueras comment les développeurs d'applications tierces feront pour développer leurs logiciels sans ré-installer des versions supérieures des dites bibliothèques de façon concurrente et de façon harmonieuse ? Ce n'est déjà pas si simple au sein d'une même distribution alors avec de multiples tiers...

S'il n'y a pas d'évolutions importantes dans ce domaine, Linux restera "trop compliqué". Il ne faut pas oublier que pour les "gens normaux" l'ordinateur est un outil.

En même temps, l'outil qu'est l'ordinateur n'a guère évolué depuis des années et demeure pourtant trop compliqué pour certains utilisateurs.

Pour enfoncer le clou avec les développements propriétaires, leur problème est justement qu'ils ne comptent pas suivre les évolutions des ABI au rythme suivi par les logiciels libres. Il faudrait donc freiner tous les développements juste pour satisfaire quelques entreprises commerciales ? Désolé mais là, on n'est pas d'accord et sur ce point, même Linus rejoint RMS. Si les entreprises commerciales veulent VRAIMENT disposer d'un bon support sous Linux sans toutefois libérer leurs sources, qu'ils s'investissent davantage. Après, ce sont eux les demandeurs, pas nous.