Raphaël SurcouF a écrit 2609 commentaires

C'est très joli tout ça mais...
Quels sont les logiciels minimaux qu'ils se doivent de fournir ou pas ?
Admettons qu'Ubuntu soit presque sur le bon chemin : ils fournissent Linux et Gnome. Mettons de côté OpenOffice.org et Firefox car ils entreraient presque dans le cadre d'applications tiers.
Pour autant, chaque distribution sera donc fournie avec de nombreuses bibliothèques par défaut dont des bibliothèques graphiques dont dépendent ces applications tiers.
Il faudra donc que les développeurs d'applications s'en tiennent aux seules ABI fournies ou qu'ils compilent tout en statique, point.
Évidemment, cela risque de te contrarier dans tes plans de développement mais, contrairement à ce qu'il se passe sous Windows où l'API est figée, celle des bibliothèques (sans même parler du noyau) ne l'est pas. Pourquoi est-ce que les autres développeurs mettraient-ils leurs développements en berne uniquement pour satisfaire les besoins de quelques autres ?
C'est une bien belle idée mais elle n'est pas non plus réalisable sinon, il y aurait longtemps que ce serait déjà fait.

Plus de 200. Pour autant, il n'existe pas plus de 10 distributions majeures. Personne ne lui demande de supporter toutes les distributions du monde (est-il prêt à supporter RedFlag Linux ?).
De toutes façons, c'est complètement surréaliste de vouloir atteindre un tel but.
Imaginons un seul instant que le produit Miracle 1.0 lui permette d'installer son logiciel en créant un seul paquet binaire pour Linux.
Soit. Il souhaite néanmoins ne pas surcharger inutilement son paquet binaire donc il ne devra pas utiliser compilation statique.
Soit. Dans ce cas, 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 (ce qui est le cas quand on fait des mises à jour fonctionnelles ayant besoin d'être testé). 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.
Sauf qu'il va se retrouver à devoir quand même disposer de l'installation de l'utilisateur qui lui soumettra un problème après avoir installé SON paquet binaire et là, il ne pourra se retourner contre personne !

/usr/local ou /opt, c'est kif-kif pour ce genre de raisons.
Personnellement, c'est plutôt /usr/local mais ça revient au même.

Tous les trois mois signifierait que la distribution en passerait 8 par an pour stabiliser les différentes versions. Il existe des distributions qui sortent tous les 6 mois et c'est amplement suffisant.
D'ailleurs, ces distributions (comme Ubuntu pour ne pas la citer) ont connu un succès immédiat auprès du public recherchant précisément une distribution dite « stable » avec des logiciels relativement et régulièrement à jour. Ubuntu dispose même de dépôts officiels de rétro-portage au cas où ce délai semblerait trop long pour proposer un nouveau logiciel à ceux qui le désirent.
Cela convient néanmoins très bien pour les particuliers mais pas pour les professionnels (pour une fois, j'évite de diviser postes de travail et serveurs).
Donc, les logiciels libres destinés au grand public devrait réduire leurs cibles et viser uniquement les distributions orientées grand public plutôt que vouloir imposer un système bancal à toutes les distributions. J'ai lu qu'on bridait les utilisateurs « grand public » à cause des prétendus problèmes d'installation mais là, on briderait les professionnels. Comme quoi il est difficile de contenter tout le monde.

Et parce qu'avec les autres distributions, ce ne serait pas possible d'en faire autant ?

Qu'est-ce qui t'empêche de renvoyer l'utilisateur auprès de celui qui a créé le paquet binaire, surtout s'il s'agit d'une distribution ? Voire de contacter directement le responsable en plaçant l'utilisateur en copie ?

Le problème est que cela semble encore à l'initiative d'Ian Murdock pour faire avancer Progeny qui ne décolle toujours pas et cela risque surtout, au vu des acteurs actuels, tourner surtout autour du format RPM sans aller voir plus loin.
Laissons leur donc le temps de travailler sur ce sujet mais j'ai bien peur qu'il ne s'agisse qu'une forme déguisée d'un vieux débat sur la compatibilité binaire contre la compatibilité source.

Par contre je ne suis pas d'accord avec toi sur le role obligatoire des tiers packageurs. C'est une option, c'est bien mais ne doit pas être un point de passage obligé, ni pour le logiciel libre, ni pour le propriétaire. Ce système à des avantages mais aussi de nombreux inconvénients qu'on cherche tous à se masquer. Un projet libre ou propriétaire doit fournir un paquet binaire prêt à être installé, quelque soit la plate-forme, c'est indispensable.

Je suis désolé mais c'est un non-sens complet.
Tu n'es pas d'accord avec lui sur le rôle des tiers packageurs ? Donc, d'après les distributions ne servent à rien, il faudrait laisser le boulot d'installation binaires aux seuls développeurs des projets libres ?
N'est-ce pas justement par manque de temps et de personnel compétent que tu trouves la situation déplorable, alors même que tu bénéficies pour GCompris d'un support largement supérieur à la majorité des projets libres !
Un peu de décence et de cohérence ferait du bien...
Tu ne peux pas vouloir défendre la diversité quand tu demandes précisément aux éditeurs de distributions de Linux de ne faire plus qu'un ou peu s'en faut.

Pas de solutions simples ? Qu'est-ce qu'il ne faut pas entendre...

Quels utilisateurs ? Ceux qui ne répondent pas aux sondages ?
Il ne s'agit pas d'auto-satisfaction mais de ne pas non plus faire table rase des acquis. J'ai l'impression que tu confonds un peu ton besoin particulier avec ton logiciel et l'ensemble des logiciels libres. Autopackage n'est pas la panacée mais dans ton cas, la seule solution serait pour toi de fournir un gcompris compilé en statique au mépris des règles de ces distributions qui ont l'air de te gêner...
Pour ce qui est des jeux libres, il y a sans doute un modèle de mise à jour à revoir.
Tu ne vas pas me dire que tu modifies le coeur de ton logiciel tous les jours ?

On ne peut pas non plus obliger des bénévoles à travailler.

On parle surtout d'installation sur de multiples distributions Linux : que viennent faire les questions de licences payantes dans le lot hormis pour RHEL (par exemple) ?
La plupart de ces distributions ne nécessitent nullement de payer quoique ce soit pour disposer d'une version récente et stable ou de développement.
Il y a quand même un sacré gouffre entre le fait de bien vouloir passer du temps à construire un .exe pour des utilisateurs de ton Logiciel Libre sous Windows et rechigner d'en faire autant pour les différentes distributions sous prétexte qu'il y en a beaucoup. Il y a 2 systèmes de gestions de paquets binaires majeurs à maitriser, pour le reste, les différences entre les distributions tiennent à quelques « détails » si tu me passes l'expression.
Quand je vois l'éventail des paquets binaire proposés pour Gcompris, il est loin d'être mal lotis et j'ai encore plus de mal à comprendre où serait son problème pour savoir ce que ses utilisateurs utilisent, à moins qu'il ne s'agisse des systèmes utilisés par les développeurs ? Dans ce cas, la boucle est bouclée.
Pour finir, si tu doutes des tests effectués par les responsables des distributions et tu préfères t'en remettre à des RC alors tes utilisateurs sont loin d'être stupides et auront plutôt intérêt à savoir te remonter les problèmes correctement pour que tu puisses y voir clair. Dans ce cas, à toi de leur fournir un paquet pour les systèmes que tu vises dans ton « marché ».
Il s'agit franchement d'un faux problème...

Tu n'es pas tout seul non plus...
Il suffit de ne pas non plus faire peur au moindre contributeur souhaitant faire un paquet binaire pour sa plate-forme particulière.
Je sais bien qu'il est difficile d'avoir toutes les plate-formes existantes mais il existe des solutions logicielles (Xen que tu as cité, mais aussi Qemu quand il ne s'agit pas que d'x86 ou d'amd64) pour t'en sortir.
Comme l'a dit « CrEv», un chroot ou sandbox suffit amplement. Sous Debian, on a l'excellent outil pbuilder qui nous permet de faire ça à la volée ce qui évite de conserver une image en permanence et d'automatiser tout ça.

Alors pourquoi proposer les paquets pour Mac OSX, Windows, plusieurs distributions Linux si tu ne sais pas toi-même quels sont les systèmes utilisés par tes utilisateurs ? Si tu n'as même pas la base de réflexion quant aux problèmes, ce n'est pas la peine d'aller plus loin : fais un sondage auprès d'eux et tu seras plus vite fixé.
Je suis désolé mais si tu as un tant soit peu de soucis envers tes utilisateurs, la part de tests et d'intégration avec le système qu'ils utilisent est non négligeable et doit être intégré à ton processus de développement.
Sinon, c'est que tu t'en fous ou que tu manques simplement de personnel compétent.

Si tu trouves qu'ils manquent de sérieux, retire les liens de ta page de download et, dans le cas des paquets intégrés aux distributions, assure toi-même le travail.

En fournissant le même paquet mais pour experimental (dans le cas de Debian, à condition que son responsable veuille bien le faire) ou de en le proposant vous-même en reprenant légèrement le paquet source avec uupdate (merci aux responsables qui ajoutent le debian/watch).
Si tu n'es pas satisfait de la réactivité des versions dans une distribution particulière ET que le gestion des dépendances d'un outil comme Autopackage laisse à désirer, il faut s'investir dans la création du paquet : il n'y a guère le choix.

Et ce que fait également Debian avec son réseau de buildd pour ses 11 architectures.

Hummm, au temps pour moi, c'est à la génération du paquet RPM qu'il exploite le ldd et les shells utilisés. Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.

Surtout que des distributions comme Debian prévoient précisément de signaler le besoin d'un logiciel qui n'est pas encore disponible sous forme de paquets : RFP (à ne pas confondre avec ITP qui signifie qu'on est en train de le réaliser).

RFP : Request For Package
ITP : Intent To Package

Ce qui tend à confirmer qu'il faudrait que vous vous occupiez vous-même de la création des paquets binaires des distributions majoritairement utilisées par vos utilisateurs ou d'assurer une co-maintenance du paquet officiel avec le ou les responsables tiers de manière à pouvoir faire un NMU (désolé pour le jargon Debian) uniquement sur tes paquets.
Évidemment, le système de Debian se prête peu à cela car n'importe quel DD peut techniquement réaliser un NMU. Je dis bien techniquement car politiquement, certains DDs sont plutôt susceptibles et il vaut mieux avoir l'accord du responsable officiel pour en faire un. Heureusement, peu d'entre-eux s'en offuscent vraiment s'ils ont vraiment manqué de temps.
Que les responsables de paquets ne testent pas leurs paquets, c'est leur ...responsabilités... et cela rejoint le premier paragraphe : il faut vous investir davantage dans la gestion du paquet en question.

Ce serait normalement le rôle du responsable du paquet de la dite distribution de remonter le problème aux développeurs amonts s'il s'avère que le problème n'est pas propre à la distribution. Là, ce responsable est quand même mieux placer que l'utilisateur pour en déterminer la pertinence.
En outre, il suffirait que les développeurs amonts n'attendent pas que les responsables de paquets les contactent pour régler des problèmes et se pré-occupent davantage de la qualité de communication entre eux (du moins, pour ceux qui se pré-occupent déjà de leurs utilisateurs).

J'exagère à peine : il n'y a qu'à regarder les require de la majeure partie des paquets RPM. Il suffit souvent de disposer du fichier adéquat pour que le RPM accepte de s'installer. Ce n'est pas simplement rare, c'est largement utilisé.
Et quand on donne le choix aux utilisateurs, c'est comme des électrons, ils choisiront le chemin le plus court (comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).

De toutes façons, les versions rc n'ont pas leurs places dans les versions de développement de la plupart des distributions et notamment de debian.
Par contre, rien ne t'empêche de créer ton propre dépôt pour les distribuer ou de passer par experimental si toi ou l'un de tes développeurs est un DD officiel.

Au moins, on pourra sortir Debian stable dans les temps impartis (3 ans pour Windows). ;-)

Linagora n'est pas une distribution mais une SSLL.
Un peu gros comme troll.