Journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
76
28
oct.
2014

J’écris cet article pour vous raconter ma mésaventure et vous avertir des problèmes au devant desquels vous allez si vous décidez de packager pour Debian un logiciel que vous avez vous-même créé. C’est en quelque sorte une réponse à https://wiki.debian.org/AdvantagesForUpstream.

Je suis le créateur du jeu MiceAmaze, un petit jeu avec des souris et des serpents que j’ai écrit en C++ et qui utilise OpenGL pour le rendu. Le jeu est conçu dès l’origine pour marcher à la fois sous Windows et Linux.

Dès le début, j’étais conscient que pour que le package soit inclus dans Debian, il fallait respecter certaines conventions comme placer aux bons endroits les fichiers (dans /usr/share les data, dans /usr/bin les binaires, etc.) et qu’il fallait fournir une page de man, un Makefile compatible avec le système de compilation de Debian, etc. Mais le problème n’est pas là.

Le problème c’est que si vous êtes le créateur du logiciel que vous essayez d’inclure à l’archive Debian, il ne faudra pas simplement que le packaging soit fait correctement, mais que le design de votre logiciel convienne aux responsables de chez Debian.

Tout d’abord on m’a demandé de changer la manière dont le texte est affiché à l’écran. Je commence par ça car c’est la demande qui me parait la plus justifiée. Vous le savez si vous avez déjà fait du OpenGL : il n’y a rien d’inclus de base pour le rendu du texte qui soit cross-platform. Pour éviter le problème, j’avais donc créé des images PNG avec mon texte que je chargeais comme textures. On m’a demandé de changer ça et on m’a suggéré d’utiliser la librairie QuesoGLC. Cette lib n’est pas très répandue et si vous n’utilisez pas Debian, vous n’avez probablement pas de package. Néanmoins cela fonctionne bien… sous Linux, car sous Windows cela plante systématiquement et pas moyen de la faire marcher. Au final je choisis donc de créer un ensemble de fonctions que j’appellerai de manière générique et qui sous Windows appelleront le système de rendu de texte intégré spécifique de l’OS, et qui sous Linux appelleront QuesoGLC. Au final cela fonctionne (après beaucoup de travail), et l’on ne voit aucune différence du point de vue utilisateur avec la version précédente (en fait le rendu est un peu moins bon sous Linux).

Ensuite, il faudrait également que l’icône du logiciel (en 64x64 pixels), qui est une souris, soit générée à partir de l’image grand format utilisée dans le jeu, en utilisant ImageMagick pour la redimensionner à la compilation, plutôt que de fournir une icône 64x64 toute faite (on va sûrement économiser quelques centaines d’octets grâce à ça…).

Ensuite, il y a une image PNG (celle de l’aigle) dont on devine qu’elle a été créée à partir d’une image vectorielle. C’est le cas, elle vient d’OpenClipart (domaine public) et j’avais ensuite modifié une version PNG avec GIMP (pour changer les couleurs). On me dit que je ne devrais pas fournir l’image PNG mais plutôt une version SVG qui serait transformée en PNG à la compilation. Cela ajoute donc une dépendance vers la librairie RSVG pour compiler mon jeu (pour générer 2 images au final). Quand je réponds que avec RSVG et ImageMagick on va ajouter plein de dépendances pour quelqu’un qui veut compiler mon jeu sous Linux et que ça va compliquer la vie de ceux qui veulent l’essayer on me répond de manière sarcastique que si je ne voulais pas qu’il y ait de dépendances, je n’ai qu’à inclure aussi X11 et le noyau Linux dans mon tar.gz. Au final je reprends l’image SVG de départ, refais avec Inkscape les modifications que j’avais originalement faites initialement sur le PNG directement, et j’inclus dans le Makefile l’appel à rsvg-convert. Pour la version Windows je n’ai aucune envie de faire une compilation si compliquée donc je garde l’image PNG initiale.

Dans la liste des changements que j’ai le droit de remettre à une version ultérieure il y a la présence de caractères latin1 et non ASCII dans le code. En fait il s’agit uniquement du symbole copyright pour afficher en bas de l’écran d’accueil du jeu. Passer cela en UTF-8 nécessiterait de mettre du code non cross-platform car Windows et Linux gèrent cela différemment.

Je serais aussi censé assurer la compatibilité avec SDL 2. En fait cela nécessite de réécrire des parties entières du code donc je n’ai aucune intention de le faire (à ce moment là SDL 2 n’était pas encore incluse dans une version stable ou testing de Debian).

Au final MiceAmaze a été inclus dans Debian après 3 mois. Tous ces changements m’ont pris au total plusieurs jours de travail, mais qui n’ont du point de vue utilisateur produit aucune différence (même pas en termes de FPS plus élevées) à tel point que pour la version Windows j’avais laissé la version précédente car on ne voyait aucune différence. J’ai passé autant de temps à changer toutes ces choses là à l’époque qu’à améliorer le logiciel d’un point de vue fonctionnalités par la suite. Je n’ai pas eu le courage de recommencer tout ça, ce qui fait que la dernière version (3.0) n’est pas incluse dans Debian (qui a la 1.8). Mais je n’ai pas envie de doubler mon temps de travail à chaque fois que j’ajoute une fonctionnalité dans le logiciel, je préfère utiliser ce temps pour ajouter deux fois plus de fonctionnalités…

Ma conclusion est que je vous décourage d’inclure vous-même un logiciel que vous avez créé dans Debian. Si vous packagez le logiciel de quelqu’un d’autre, on ne vous demandera pas de le modifier car vous n’êtes pas l’auteur. Inversement si vous êtes l’auteur, la personne qui le package ne vous demandera pas non plus de modifier votre logiciel (elle ne fait que le packager).

NdM : l'auteur du journal nous a demandé le 29/10 d'ajouter ce correctif :

La publication de cet article a entraîné une discussion avec les personnes concernées chez Debian. Il s’avère que beaucoup des demandes dont je parle n'étaient pas obligatoires. Cependant, le contexte m'avait laissé penser le contraire, il s'agit alors d'une erreur de ma part et je m'en excuse. Au final, cela ne devrait pas vous dissuader d'inclure vos logiciels dans Debian. Je compte pour ma part essayer d'inclure la dernière version de mon logiciel en prenant en compte ces nouvelles données.

  • # Bonnes pratiques

    Posté par  . Évalué à 4.

    Ne pas avoir dans les sources des produits générés me semble être une très bonne pratique.

    Dans le cas du texte en png, quelqu'un voulant faire une traduction pourra le faire beaucoup plus facilement si l'image est générée.
    Le svg sera plus facile à suivre dans le gestionnaire de versions, répond en partie à la problématique des résolutions multiples.

    • [^] # Re: Bonnes pratiques

      Posté par  (site web personnel) . Évalué à 10.

      Ne pas avoir dans les sources des produits générés me semble être une très bonne pratique.

      C'est très discutable pour tout ce qui est artistique. Chacun utilise l'outil qu'il maitrise le mieux.

      Dans le cas du texte en png, quelqu'un voulant faire une traduction pourra le faire beaucoup plus facilement si l'image est générée.

      C'est pas le problème de Debian mais de l'auteur du logiciel. Et ce n'est pas la seul méthode.

      Le svg sera plus facile à suivre dans le gestionnaire de versions, répond en partie à la problématique des résolutions multiples.

      Mais ce n'est pas le problème de la distribution !

      "La première sécurité est la liberté"

      • [^] # Re: Bonnes pratiques

        Posté par  . Évalué à 1.

        Debian veut avant tout faire progresser le logiciel libre. Pour ça il faut que ses logiciels soient facilement modifiables.
        Dans le cas des images, c'est plus simple si les sources (svg, images avec calque ou image haute résolution) sont disponibles.

        Techniquement ce n'est pas nécessaire pour distribuer un logiciel, mais ça l'est si le but est le logiciel libre.

        • [^] # Re: Bonnes pratiques

          Posté par  . Évalué à 1.

          | Debian veut avant tout faire progresser le logiciel libre. Pour ça il faut que ses logiciels soient facilement modifiables.

          Certes mais l'avantage du libre c'est surtout de pouvoir modifier soit même. Si ces demandes/suggestions sont si importantes pour eux, ils sont libres de patcher le jeux. Surtout que l'ajout de dépendances, pour un jeu, est généralement une mauvaise chose. Quelques recherches rapides et non exhaustives m'informe que la dernière version (0.7.2) date de 2009. J'ai toujours quelques réticences à ajouter des dépendances non maintenues depuis 5 ans. Mais bon, il est vrai que pour debian, 2009, c'est maintenant.

      • [^] # Re: Bonnes pratiques

        Posté par  . Évalué à 4.

        C'est très discutable pour tout ce qui est artistique. Chacun utilise l'outil qu'il maitrise le mieux.

        On peut aussi regarder ça du point de vue de la licence libre. Le png est au binaire ce que le svg est au code source. Du coup, si tu places ton code sous GPL ou équivalent, tu es censé fournir le code source pour les logiciels, les images, les sons, etc.

        Mais ce n'est pas le problème de la distribution !

        Visiblement, Debian considère que si. Tu ne peux pas reprocher à une distrib de ne pas faire de contrôle qualité : Debian vérifie les licences, la qualité générale du soft (pas de virus ni de malware, le logiciel s'exécute, etc), la conformité avec le règlement (de mémoire, il y avait eu des problèmes avec les jeux de mots débiles de weboob), etc. D'une manière générale, Debian reste concerné par la stabilité du système et la pertinence des logiciels packagés; si un soft pourrit le système parce qu'il est mal codé, c'est quand même le problème de la distribution! D'une manière générale, je pense qu'une distribution ne doit rien aux développeurs ; inclure un logiciel dans Debian, c'est un peu comme inclure un patch dans le noyau ; on peut te demander tout un tas de trucs et finir par dire "non". Tu as le droit de le prendre mal, tu as le droit d'être en désaccord avec la décision, mais si tu as accepté de passer autant de temps à essayer de faire passer ton truc, c'est que tu considères que la qualité du projet fait que ça valait la peine de faire des efforts. Or, cette qualité, c'est justement la raison qui fait que le processus est aussi chiant. À moins d'être complètement schizophrène, je ne vois pas comment tu peux te plaindre de la rigidité d'une projet, que tu as choisi justement du fait de sa qualité.

        Sur le fond, je ne connais pas les tenants et les aboutissants spécifiques des problèmes rencontrés, mais ils me semblent tous aller vers une amélioration de la qualité du logiciel, en privilégiant les solutions générales (réutilisation de bibliothèques existantes, refus de divers bricolages à des fins de portabilité, demande de compilation à partir des vraies sources…). Ça se fait au détriment de la portabilité par contre (notamment en proposant d'utiliser des trucs Debian spécifique), mais ça, j'aurais tendance à dire que ça n'est pas le problème de Debian (ou seulement indirectement, car ils prennent le risque de ne pas pouvoir proposer certains logiciels à leurs utilisateurs).

        • [^] # Re: Bonnes pratiques

          Posté par  (site web personnel) . Évalué à 10. Dernière modification le 28 octobre 2014 à 14:02.

          On peut aussi regarder ça du point de vue de la licence libre. Le png est au binaire ce que le svg est au code source. Du coup, si tu places ton code sous GPL ou équivalent, tu es censé fournir le code source pour les logiciels, les images, les sons, etc.

          Oui mais ce n'est pas le cas, car il avait modifié le bitmap à la main.

          [..]; si un soft pourrit le système parce qu'il est mal codé

          De tout ce que tu as noté avant, aucuns des reproches fait à l'auteur ne rentre dans tes cases.

          À moins d'être complètement schizophrène, je ne vois pas comment tu peux te plaindre de la rigidité d'une projet, que tu as choisi justement du fait de sa qualité.

          Si le packageur n'était pas le codeur, il n'y aurait aucune modification. Il y a donc 2 poids 2 mesures. On dirait se poindre les stupidités de Wikipedia, qui tue toute envie de participer.

          ils me semblent tous aller vers une amélioration de la qualité du logiciel, en privilégiant les solutions générales

          Pas vraiment non, puisque les dépendances augmentent et que la personne a perdu 3 mois, sans aucun gain pour l'usager, et il n'a pas un code plus simple non plus (vrai gage de qualité) à cause des bidouilles de portabilité. "Le mieux est l'ennemi du bien".

          "La première sécurité est la liberté"

        • [^] # Re: Bonnes pratiques

          Posté par  . Évalué à 10.

          Dans le cas de l'image, d'après l'auteur du journal elle était originellement dans le domaine public. À partir de là, le PNG l'est aussi si l'auteur le désire, et distribuer le PNG respecte la licence. Ce n'est pas du logiciel !

          Pour les modifications du logiciel sur la façon dont sont affichés les textes (QuesoGLC), ça n'est pas un problème de licence, ça ne peut être qu'un problème de qualité pour les développeurs Debian. Il est certain qu'afficher du texte de manière configurable plus propre qu'une image de texte est mieux. Mais conditionner l'inclusion à ça clairement abusif ! Le développeur du logiciel a fait un choix simple, rationnel, modifiable par ceux qui le veulent (changer les images PNG reste du domaine du possible tout de même !). Je pensais qu'Unix (et un peu Debian), c'était KISS !

          • [^] # Re: Bonnes pratiques

            Posté par  . Évalué à 0. Dernière modification le 28 octobre 2014 à 14:20.

            Je pensais qu'Unix (et un peu Debian), c'était KISS !

            Unix, oui; Mais GNU is Not Unix. Et Debian, c'est : "pourquoi faire simple quand on peut faire compliqué" ( Et je ne parle même pas de GNU/Linux depuis l'arrivée de systemd …).

          • [^] # Re: Bonnes pratiques

            Posté par  (site web personnel) . Évalué à 3.

            Dans le cas de l'image, d'après l'auteur du journal elle était originellement dans le domaine public. > À partir de là, le PNG l'est aussi si l'auteur le désire, et distribuer le PNG respecte la licence. Ce n'est pas du logiciel !

            Tout ce qui est distribué dans Debian doit respecter la DFSG qui impose la présence des sources. Ce point a été clarifié lors d'une GR et s'applique aussi aux images. La licence originale peut être plus permissive mais l'ensemble doit respecter la DFSG quand même, sinon, ça ne rentre pas dans Debian.

            • [^] # Re: Bonnes pratiques

              Posté par  . Évalué à 9.

              Ce point a été clarifié lors d'une GR et s'applique aussi aux images.

              Où l'on peut lire :

              Ainsi, ces travaux doivent contenir la forme que le détenteur de droits ou le développeur amont utilise réellement pour les modifier ;

              C'est en effet extrêmement clair.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Bonnes pratiques

                Posté par  (site web personnel) . Évalué à 4.

                C'est "the preferred form of the work" de la GPL. C'est logique. Il y a un problème uniquement si on exige d'un jeu qui a tout en bitmapp de faire du vectoriel pour avoir un "source" des images.

                "La première sécurité est la liberté"

        • [^] # Re: Bonnes pratiques

          Posté par  (site web personnel) . Évalué à 10.

          « Le png est au binaire ce que le svg est au code source. »

          Ce ne serait pas plutôt le png est au svg ce que le binaire est au code source ?

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

          • [^] # Re: Bonnes pratiques

            Posté par  . Évalué à 9.

            et quand bien même, c'est faux, puisqu'on ne pourra pas toujours produire du png (bitmap) depuis un svg (format vectoriel), par exemple cas d'une photo.

            C'est sûr que c'est mieux de travailler sur des svg lorsque c'est possible, mais comme dit plus haut, c'est le travail et le choix du développeur, là ça ressemble un peu à de l'abus de pouvoir.

            « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

            • [^] # Re: Bonnes pratiques

              Posté par  (site web personnel) . Évalué à 9.

              et quand bien même, c'est faux, puisqu'on ne pourra pas toujours produire du png (bitmap) depuis un svg (format vectoriel), par exemple cas d'une photo.

              De plus on veut pouvoir tuner à la main le rendu du PNG. Le vectoriel est affichable à toute résolution, mais souvent il est plus élégant de redessiner dans les petites résolutions. Par exemple les packs d’icônes courants fournissent généralement des bitmaps pour les petites résolutions en plus du vectoriel.

              ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Bonnes pratiques

            Posté par  (site web personnel) . Évalué à 2.

            Bah, ça marche aussi, non ?

             a     b      a     x
--- = ---  ≡ --- = ---
 x     y      b     y

            blog.rom1v.com

    • [^] # Re: Bonnes pratiques

      Posté par  . Évalué à 10.

      Ne pas avoir dans les sources des produits générés me semble être une très bonne pratique.

      Adopter une règle comme un dogme n'ai jamais une bonne idée.

      Rien de ce qui était reproché ne modifie le comportement final, il n'y a pas de raison pour que ce soit bloquant. Ils auraient très bien pu accepter le paquet et créer une série de rapport de bug. L'avantage c'est :

      • de ne pas dégouter quelqu'un de contribuer : c'est hyper important pour la survie du projet (même pour un aussi gros que Debian) ;
      • avoir une approche agile et viser une amélioration progressive des paquets ;
      • être totalement transparent sur ce qui est demandé, avoir une organisation clair des discussions, les historiser plus facilement et plus clairement que sur des listes de diffusions (là elles sont liées au paquet) ;
      • si en cours de route l'auteur claque la porte tout le travail n'est pas perdu, quelqu'un peu récupérer le paquet retrouve quels sont les problèmes en cours et peu commencer à travailler.

      Sincèrement. Ce qui est décris dans ce journal (si c'est bien le cas, c'est quand même mieux avec un lien), c'est vraiment de la merde. Une organisation pourrie qui semble plus imposer des dogmes que de chercher à être productif.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Bonnes pratiques

        Posté par  . Évalué à 10. Dernière modification le 28 octobre 2014 à 15:52.

        J'ai cherché et rapidement décrit les échanges avec le sponsor un peu plus bas.

        La plupart des demandes abusives décrites par Almacha dans ce journal semblent surtout avoir été des suggestions pour que le logiciel soit de meilleure qualité. Et à aucun moment il n'a dit « ça demande beaucoup de boulot, est-ce que c'est vraiment bloquant pour l'intégration du paquet à la distribution ? », se contentant de râler 8 mois plus tard sur linuxfr.

        Je trouve plutôt positif qu'un développeur Debian ait pris autant de temps pour la review d'un paquet finalement peu critique pour le projet (jeu peu connu).

        • [^] # Re: Bonnes pratiques

          Posté par  . Évalué à 4.

          D'où mon "si c'est bien le cas, c'est quand même mieux avec un lien" :)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Bonnes pratiques

            Posté par  . Évalué à 2.

            Au final, peut être uniquement un problème de maîtrise de l'anglais. Moi qui suis nul…

  • # WTF ?!

    Posté par  (site web personnel) . Évalué à 10.

    Pourquoi Debian a une politique aussi idiote ? Sachant que si il y a 2 personnes au lieu d'une, elle n'est pas appliqué ?

    "La première sécurité est la liberté"

  • # Liens ?

    Posté par  (site web personnel) . Évalué à 4.

    Mouais, facile de critiquer sans citer.

    La plupart des critiques semblent venir du fait qu'on t'a demandé de t'assurer que les assets sont bien compilés depuis les sources. C'est une condition pour être compatible avec la DFSG. Il n'est toutefois pas interdit de fournir des assets précompilés, il faut juste que lors de la construction du paquet Debian, ces assets soient recompilés et donc que les sources soient présentes. Pour les autres utilisateurs, il n'y a donc aucune dépendance à ajouter, ils utiliseront les assets précompilés. Et cela n'a rien à voir avec le fait que tu sois upstream.

    À partir de là, je prends les autres critiques avec des pincettes vu qu'on a bien dû t'expliquer la raison et que tu préfères en donner une autre ("on va sûrement économiser quelques centaines d’octets grâce à ça").

    • [^] # Re: Liens ?

      Posté par  (site web personnel) . Évalué à 5.

      Si, pour les utilisateurs qui partent des sources, ils ont 2 dépendances de plus à gérer.

      "La première sécurité est la liberté"

      • [^] # Re: Liens ?

        Posté par  (site web personnel) . Évalué à 1.

        Il peut laisser les assets précompilés dans les sources. Les utilisateurs qui n'ont pas les dépendances continuent à les utiliser.

        • [^] # Re: Liens ?

          Posté par  (site web personnel) . Évalué à 9.

          Il y a donc 2 systèmes de build qui cohabitent ? Et c'est censé être un point de qualité ?

          "La première sécurité est la liberté"

          • [^] # Re: Liens ?

            Posté par  . Évalué à 2.

            Heu, tu sais qu'un Makefile ne va pas demander de recompiler tes « assets » si leur source n'a pas été modifiée ? Et ce n'est n'est qu'un (relativement) simple système de construction.

            • [^] # Re: Liens ?

              Posté par  (site web personnel) . Évalué à 2.

              Dans ce cas, les assets ne sont jamais (re)construit.

              "La première sécurité est la liberté"

              • [^] # Re: Liens ?

                Posté par  . Évalué à 6.

                Heu… si, quand les sources des assets sont modifiés. (j'ai l'impression de me répéter) Tu veux reprendre les bases de make avec moi ?

                • [^] # Re: Liens ?

                  Posté par  (site web personnel) . Évalué à 0.

                  Il n'a pas de raisons de modifier les assets, puisqu'à l'origine ils sont fait à la main. Donc, il n'a pas de raisons de vouloir les regénérer ensuite.

                  "La première sécurité est la liberté"

                  • [^] # Re: Liens ?

                    Posté par  (site web personnel) . Évalué à 4.

                    Dans debian/rules, le mainteneur touch les assets source et paf, ça reconstruit. Ou on efface les assets cibles et ça reconstruit aussi.

                  • [^] # Re: Liens ?

                    Posté par  . Évalué à -2.

                    WTF ? Toi parler français ? Je ne comprends rien à ton argumentation sur un soit-disant besoin de deux systèmes de build.

                    • [^] # Re: Liens ?

                      Posté par  . Évalué à 7.

                      Lui y en a expliquer que le PNG n'est pas bêtement généré à partir du SVG, mais fignolé à la main. Et, oui, c'est une pratique courante si tu veux des graphiques bitmap bien léchés.

                      • [^] # Re: Liens ?

                        Posté par  . Évalué à 1.

                        Oui, tout à fait. Mais en quoi cela nécessiterait-il « deux systèmes de build » ?…

    • [^] # Re: Liens ?

      Posté par  . Évalué à 7.

      Mouais, facile de critiquer sans citer.

      Exactement. Des noms, des noms !

    • [^] # Re: Liens ?

      Posté par  . Évalué à 10. Dernière modification le 28 octobre 2014 à 15:31.

      Avec une rapide recherche ("debian miceamaze rfs"), on peut trouver :

      I would strongly suggest that the text be rendered at runtime or at
      the very least the PNG files created from the DejaVu font should
      rendered at build time from ttf-dejavu. Rendering the text at runtime
      will allow you to add translations, making the game accessible to more
      users. I would recommend quesoglc for this.

      Aucune obligation d'utiliser quesoglc donc, créer les fichiers png au build aurait été suffisant.

      The changes for the eagle silhouettes look like they could be done
      easily in the SVG by changing the stroke and fill colours. For the
      other image it would be slightly harder but doable. For both of them,
      modifying the SVG and rendering the result automatically would have
      provided much better quality images.

      Là encore, des suggestions.

      Finalement, on peut lire cet échange de façon complètement différente de ce qu'a décrit l'auteur du journal : il a voulu packager son logiciel, a cherché un sponsor, et un développeur Debian a non seulement répondu sous 24h pour expliquer pourquoi le paquet ne pouvait pas être intégré immédiatement (parfois en fournissant directement la solution, tel que le Makefile), mais y a en plus ajouté des suggestions pour améliorer le logiciel.

      • [^] # Re: Liens ?

        Posté par  . Évalué à 10.

        J'étais en train d'écrire une réponse similaire après avoir lu les échanges sur debian-mentors, donc je me permets de compléter au lieu de poster un doublon.

        Dans ce message, ton sponsor indique également que les caractères en latin-1 sont « not an issue at all ». Ce n'est pas un problème qu'on te permet de résoudre plus tard puisque ce n'est pas un problème du tout.

        Concernant SDL2, tu n'es pas censé assurer la compatibilité avec cette bibliothèque, on t'a juste fait remarquer qu'elle arriverait bientôt dans Debian et que tu pourrais vouloir rendre ton jeu compatible.

        Au final, ton paquet a été uploadé un mois après ton ITP (que tu avais par ailleurs oublié de fermer) et a mis deux mois de plus à atteindre l'archive (il me semble que c'est un délai correct pour les paquets qui attendent dans la liste new ).

        Voilà, c'est vraiment dommage que tu aies si mal vécu l'empaquetage de ton paquet pour Debian, d'autant plus que tout cela s'est passé il y a plus d'un an et demi.
        Ou alors, c'est parce que tu viens d'apprendre que ta version 3 allait manquer le freeze ?

  • # Est-ce toujours comme ça?

    Posté par  . Évalué à 10.

    Ce que tu rapportes me choque, je ne sais pas si je suis le seul ou pas.
    On sait que les mainteneurs de paquets Debian sont connus pour patcher énormément tout ce qui vient d'amont, je ne sais même pas si c'est vrai ou si c'est de la légende urbaine.

    Là, je trouve que ton interlocuteur a largement dépassé les bornes. Je pense aussi que si tu étais "simple" empaqueteur, personne ne t'aurait demandé de faire autant de changements. La conversion de SVG vers PNG à la compilation, je comprends que ce soit très classe et très "générique", mais c'est aussi le choix du développeur amont, je ne pense pas que ça ait sa place dans la discussion sur l'empaquetage.

    Au final, je me demande si ton interlocuteur voulait que tu fasses un paquet pour Debian ou une application exclusive Debian. Si ce que tu dis de QuesoGLC est vrai, le travail de maintenance de ton appli va augmenter significativement pour un gain nul (et on te suggèrera peut-être de laisser "les autres" faire un paquet QuesoGLC dans "leur" distros s'ils râlent).

    À ta place, j'abandonnerais effectivement le paquet, et je n'oublierais pas de mettre en gros et gras les raisons de cet abandon.

    Et c'est un utilisateur inconditionnel de Debian qui écrit!

    • [^] # Re: Est-ce toujours comme ça?

      Posté par  . Évalué à 8.

      On sait que les mainteneurs de paquets Debian sont connus pour patcher énormément tout ce qui vient d'amont, je ne sais même pas si c'est vrai ou si c'est de la légende urbaine.

      Je crois que c'est pareil dans beaucoup de distribs. Récemment j'ai vu un Python avec une liste de patches longue comme le bras (je ne sais plus quelle distrib c'était, désolé).

      À la grande époque où j'utilisais Mandrake/Mandriva, les mainteneurs ajoutaient même des bugs… Peut-être pour protester contre des salaires trop bas ;-)

      Je pense qu'il y a une mentalité consistant à découvrir des problèmes supposés, sans même se demander si ce n'est pas une décision réfléchie et délibérée de la part de l'upstream. Après il y a aussi des logiciels upstream mal maintenus (ou prévus pour une autre distrib) qui nécessitent une grande quantité de patches.

  • # schizophrénie

    Posté par  (site web personnel) . Évalué à 8.

    Si vous packagez le logiciel de quelqu’un d’autre, on ne vous demandera pas de le modifier car vous n’êtes pas l’auteur. Inversement si vous êtes l’auteur, la personne qui le package ne vous demandera pas non plus de modifier votre logiciel (elle ne fait que le packager).

    Sur internet tu es invisible et anonyme sauf pour les ordures gouvernements.
    Tu n'as qu'à te faire une double personnalité pour le package de ton soft ;-)

    Même si je comprend les arguments du type :

    Le svg sera plus facile à suivre dans le gestionnaire de versions, répond en partie à la problématique des résolutions multiples.

    ça représente beaucoup de travail pour un résultat ayant plus de dépendances et même pas multi-plateforme et en plus ça décourage les créateurs de softs de programmer sous Linux.
    Mais peut être est ce une étape douloureuse mais nécessaire vers l’excellence ?

    Ma conclusion est que je vous décourage d’inclure vous-même un logiciel que vous avez créé dans Debian

    Maintenant avec le recul si tu avais à refaire un logiciel ne prendrais tu pas directement les bonnes pratiques de Debian avec des outils/libraries adaptés aussi pour Windows afin d'avoir mainstream un logiciel plus portable ?

    kentoc'h mervel eget bezan saotred

    • [^] # Re: schizophrénie

      Posté par  . Évalué à 7.

      Sur internet tu es invisible et anonyme sauf pour les ordures gouvernements.
      Tu n'as qu'à te faire une double personnalité pour le package de ton soft ;-)

      Multiplier les identités pour une raison aussi idiote, c'est quand même marcher sur la tête.

      Je vois pas en quoi Debian (ou tout autre projet communautaire) gagne à se créer une politique d'acceptation aussi conne que celle d'Apple sur l'App Store.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: schizophrénie

        Posté par  (site web personnel) . Évalué à 5.

        Multiplier les identités pour une raison aussi idiote, c'est quand même marcher sur la tête.

        Bien entendu mon commentaire (bien que concrètement fonctionnel) était à forte tendance humoristique.

        Je vois pas en quoi Debian (ou tout autre projet communautaire) gagne à se créer une politique d'acceptation aussi conne que celle d'Apple sur l'App Store.

        Il serait peut être intéressant de poser la question en ces termes aux personnes qui ont demandées à Almacha de faire toutes ces modifs.

        kentoc'h mervel eget bezan saotred

  • # Sources et versions compilées

    Posté par  (site web personnel) . Évalué à 10.

    Dans Debian, un logiciel doit être fourni avec ses sources, ça c'est un fait largement connu. Et effectivement, un truc comme une image raster en PNG préparée à partir d'une image vectorielle ne sera pas considérée comme le code source : le source, c'est le SVG. Ce genre de cas se retrouve également avec, par exemple, du code JavaScript minifié (le source, c'est le JavaScript d'origine) ou des pages de manuel issues d'une conversion avec quelque chose comme Pandoc (le source, c'est le DocBook, ou la Markdown, ou le je ne sais quoi d'origine). Voire même avec du code C généré à partir de code Vala. Bref, sans être un cas très fréquent, ça n'a rien d'exotique comme problème.

    Est-ce à dire qu'il faut obligatoirement tout regénérer à la compilation ? Non, pas nécessairement : ce qui est essentiel, c'est de fournir tout le source. Pas forcément de tout regénérer à chaque compilation : ça, c'est un choix que fera celui qui le compilera, ou celui qui en fera un paquet pour sa distribution.

    Quelle est la solution raisonnable donc ? Eh bien, dans le cas d'une image, fournir dans le tarball distribué à la fois le source en SVG et la version PNG, et mettre dans ce répertoire un Makefile qui permette de regénérer cette dernière. Les utilisateurs directs du tarball ne l'utiliseront probablement pas, mais le mainteneur d'un paquet, s'il y tient, ira déclarer une dépendance de construction sur ImageMagick et utilisera ce Makefile.

    • [^] # Re: Sources et versions compilées

      Posté par  . Évalué à 10.

      Pour les images c'est discutable quand même…

      Si tu pars d'un SVG pour faire une image raster que tu modifies à la main ensuite avec un logiciel de retouche pour ajouter des ombres, dessiner un détail… Bah ce n'est pas de la compilation. Sinon pour les images entièrement créées en bitmap, il faut fournir un png blanc et un script Gimp pour refaire toutes les étapes du dessin ?

      • [^] # Re: Sources et versions compilées

        Posté par  . Évalué à 4.

        D'après ce que j'ai compris, pour les images avoir le source n'est pas obligatoire. Mais la démarche voudrait que si tu peux fournir le source, c'est mieux.

        Dans Debian il y a d'autres logiciels avec des images sans forcément les sources, et ça ne pose pas de soucis particulier.

    • [^] # Re: Sources et versions compilées

      Posté par  . Évalué à 9. Dernière modification le 28 octobre 2014 à 15:19.

      Dans Debian, un logiciel doit être fourni avec ses sources, ça c'est un fait largement connu. Et effectivement, un truc comme une image raster en PNG préparée à partir d'une image vectorielle ne sera pas considérée comme le code source : le source, c'est le SVG.

      Imaginons que je fork un logiciel quelconque, disons Gnome et que je l'appel Mate. Je dois fournir les sources de Gnome et un monstro patch ?

      Parce que c'est ce qu'il a fait, il a pris une oeuvre libre de droit et la forké pour son projet.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Sources et versions compilées

        Posté par  (site web personnel) . Évalué à 3.

        Je dois fournir les sources de Gnome et un monstro patch ?

        fournir le code source te permettant de générer ce que tu distribues, la forme n'est pas précisée (un tarball accompagnant les binaires est possible).

        il a pris une œuvre libre de droit

        c'est du logiciel libre et non libre de droit pour autant… une (des) licence(s) s'appliquent.

        • [^] # Re: Sources et versions compilées

          Posté par  . Évalué à 2. Dernière modification le 28 octobre 2014 à 15:34.

          c'est du logiciel libre et non libre de droit pour autant… une (des) licence(s) s'appliquent.

          Ouai enfin…

          C’est le cas, elle vient d’OpenClipart (domaine public) et j’avais ensuite modifié une version PNG avec GIMP (pour changer les couleurs).

          Sur le site on peut lire :

          Each artist at Openclipart releases all rights to the images they share at Openclipart.

          Qui pointe vers la CC0. Donc effectivement, il y a une licence, mais sache que la zoophilie est interdite (du moins en France). Parce que même si légalement l'auteur ne peux pas supprimer ses propres droits c'est, ici, la volonté de l'auteur.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Sources et versions compilées

          Posté par  . Évalué à 3.

          fournir le code source te permettant de générer ce que tu distribues, la forme n'est pas précisée (un tarball accompagnant les binaires est possible).

          En effet donc pourquoi des gens se permettent de la spécifier sachant que même la DFSG n'en parle pas ?

          J'ai l'impression qu'on a 2 choses combinées :

          1. une idée précise de ce qui est une source et ce qui ne l'ai pas qui n'est spécifiée nul part et à personne, qui est donc à la tête du client. Ça signifie qu'on peut accepter ou refuser un paquet en fonction de l'humeur du moment (de base rien que ça c'est pourri) ;
          2. l'idée que le format SVG c'est mieux que PNG donc si on peut placer du SVG partout ou on voit d'affreux PNG faisons-le. C'est du militantisme pour un format sans avoir à vraiment travailler avec.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Sources et versions compilées

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 octobre 2014 à 15:49.

            En effet donc pourquoi des gens se permettent de la spécifier sachant que même la DFSG n'en parle pas ?

            Sans doute parce que cela va aider à se faire une idée ? Que cela permet d'être opérationnel, plutôt que de se poser des questions de la manière de le faire ? (un README pour générer l'image peut convenir aussi, pas forcément besoin d'un Makefile et tout le toutim…).

            Comme indiqué plus haut, la réponse côté debian ressemble plus à des recommandations qu'à une condition obligatoire.

            C'est par exemple le genre de recommandations que j'ai déjà pu placer sur http://faq.tuxfamily.org/CommunicationLibreArt/Fr par exemple, que je devrais décliner sur http://faq.tuxfamily.org/CommunicationLibreGame/Fr d'ailleurs…

            • [^] # Re: Sources et versions compilées

              Posté par  . Évalué à 6.

              Sans doute parce que cela va aider à se faire une idée ? Que cela permet d'être opérationnel, plutôt que de se poser des questions de la manière de le faire ?

              Ça ne mérite pas plus d'une ligne ou deux dans le fichier de licence pour dire "Je me suis appuyé sur ce fichier (url), dont l'auteur est machin, sous licence CC0, merci à lui/elle pour son travail".

              Il n'y a pas à être plus opérationnel ou autre. Si je prend un logiciel est que je le fork je ne fournis pas l'original + un patch, je fourni ma version + un lien vers le projet initial. Pourquoi faire autrement ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Compréhensible dans les deux sens

    Posté par  (site web personnel) . Évalué à 6.

    On peux comprendre le responsable Debian qui souhaite avoir le source le plus "source" possible et que ça soit le plus adapté possible à Debian.

    Mais d'un autre côté, le but d'un dev c'est que ça soit utilisé facilement par ses utilisateurs et que ça soit simple à maintenir. Or, bien souvent, les demandes des packageurs font que ça sera plus complexes à maintenir sans vrai intérêt pour l'utilisateur (autre que le fait d'avoir une debian super propre à coup sûr, ce qui est déjà un bon point il est vrai).

    Je trouve donc normal que certains n'aient juste pas le temps ni l'envie de rentrer dans un système si complexe et contraignant. Là encore je ne critique pas Debian, car pour atteindre leur niveau de qualité de leur distribution ils n'ont gère le choix.

    C'est juste que pour les projets ça ne vaux pas tout le temps le coût, il ne faut donc pas s'étonner que beaucoup de projets proposent leur repo dans leur coin et laisse des versions ultra vieilles de leurs outils dans les repo des distributions.

  • # .

    Posté par  (site web personnel) . Évalué à 2.

    J'ai tendance à penser que le temps que tu as du consacrer à corriger des problèmes d'integration à Debian aurait été plus fructueusement consacré à la fabrication d'un binaire précompilé (partiellement statique pour limiter au max les dependances vers d'autres libs et avoir un binaire qui fonctionne sur toutes les distros) que tu pourrais distribuer parallelement à la version windows et aux sources. Comme ça tes utilisateurs ont toujours un accès direct à la derniere version (et pas celle vieille de trois ans qu'ils auront dans leur debian stable), tu pourras gerer les rapports de bugs directement, bref tu seras tranquille.

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 2.

      Dans un autre journal, il était question de la complexité extrème pour les distributions de mettre ensemble un grand nombre de logiciel qui n'utilise pas à la base la même sous version des libraries. La plus part des patchs viendraient de là. Vu la tonne de travail manuel que cela nécessite, n'est-il pas possible d'imaginer de faire une distribution totalement statique (à quelques exception pret genre libc, openssl, zlib,…)?

      "La première sécurité est la liberté"

      • [^] # Re: .

        Posté par  . Évalué à 3.

        stali

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

    Posté par  . Évalué à 2.

    Linus Torvalds: « One of the things, none of the distributions have ever done right is application packaging […] making binaries for linux desktop applications is a major fucking pain in the ass »

    http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm
    (Un peu avant 6 min)

    • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

      Posté par  . Évalué à 4.

      Dit le gars qui refuse de stabiliser l'ABI du noyau :-)

      • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

        Posté par  (site web personnel) . Évalué à 10.

        L'ABI INTERNE ;) Les applications n'ont rien à faire de l'ABI interne tant que l'ABI externe est stable!

        • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

          Posté par  . Évalué à 4.

          Les applications, non, mais il me semble que cela touche les modules noyau (d'où l'existence de dkms et autres hacks).
          C'est donc le même problème, à un niveau différent. Je trouve amusant que la distribution de bidules binaires est considérée par Linus comme sans importance quand il s'agit du noyau, mais pas quand il s'agit d'un bureau graphique.

        • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

          Posté par  . Évalué à 4. Dernière modification le 29 octobre 2014 à 16:00.

          Ouais enfin, Linux étant un noyau monolithique les drivers font partie du noyau, or tous les constructeurs n'adhèrent pas au mode de développement du noyau car pour nombre d'entre eux ça ne vaut pas le coup/coût de se conformer aux exigences de qualité des devs kernel pour faire rentrer leur code dans l'arbre officiel, et donc (au mieux) le bout de code est maintenu sous forme de module externe. Lorsque ledit driver n'est plus maintenu (parce que ça n'est pas rentable), l'utilisateur est livré à lui-même avec des drivers qui pètent à la première occasion… (car l'utilisateur normal ne sait pas adapter un driver. Tout ce qu'il voit c'est que son device marchait avant la MAJ de sa distro, et ne marche plus après sans aucun moyen simple de corriger le problème, à part jeter son device et en racheter un autre). Ce serait plus commode si le kernel avait des API/ABI stables pour tout ce qui est utilisé par les pilotes de périphériques ("stables" == ne changeant qu'entre versions majeures bien définies, de sorte que le script de MAJ puisse dire "attention, votre device X utilise un driver tierce-partie, la MAJ du kernel que vous vous apprétez à faire risque de rendre ce device non fonctionnel. Voulez-vous mettre à jour le noyau ?")

          Evidemment, cette remarque ne s'applique pas aux périphériques USB qui utilisent des drivers userland via libusb. De là à dire que Tanenbaum avait raison d'encourager une approche micro-kernel… ? :)

          • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

            Posté par  (Mastodon) . Évalué à 5.

            Certains constructeurs font de la merde et donc, le noyau Linux devrait s'adapter à la merde ? C'est moi où ce raisonnement a un problème ?

            • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

              Posté par  . Évalué à 1.

              Certains constructeurs font de la merde

              Faudra expliquer par quelle magie de raisonnement "ne pas être intégré dans le noyau" équivaut à "faire de la merde".

              • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                Posté par  (Mastodon) . Évalué à 3.

                Non, ce qui est décrit, c'est un constructeur qui ne veut pas être intégré dans le noyau "à cause" des standard de qualité et qui laisse tomber son module. Moi, j'appelle ça "faire de la merde". Mais tu peux appeler ça comme tu veux.

                • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                  Posté par  (site web personnel) . Évalué à 4.

                  moi j'appelle ça un constructeur non respectueux de ses clients, ce qui n'incite pas à racheter de leur matériel… par la suite (parce que oui, sur le moment, c'est énervant :/).

                • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                  Posté par  . Évalué à 4. Dernière modification le 30 octobre 2014 à 12:25.

                  Mouais si tu veux, façon de parler…

                  Mais les constructeurs de merde, ça existe et il faut bien faire avec. D'autant que ce n'est pas complètement manichéen : faire intégrer quelque chose dans l'arbre officiel est un travail de longue haleine qui requiert une forme d'expertise et d'élitisme (et il y a donc une barrière à l'entrée, et la part de marché de Linux ne justifie pas toujours l'investissement, surtout si les API/ABI pètent tout le temps alors que chez la "concurrence" elles sont stables et bien documentées). Quand je propose à quelqu'un de passer sous Linux, il est généralement déjà équipé et ne va pas choisir son matériel spécifiquement en fonction de ce qui est bien supporté, et il faut pourtant éviter que passage sous Linux soit synonyme de régressions… (ou de potentielles régressions futures à la moindre MAJ)

                  Je continue de penser que proposer des APIs stables (entre versions majeures) pour les gens qui écrivent des drivers ne serait pas un luxe. Je peux comprendre que ceux qui bossent sur la gestion de la mémoire, le scheduler, etc. souhaitent garder une liberté sur l'agencement du code interne, mais je trouve qu'un driver devrait rester un bout de code qui utilise les services du noyau (au même titre qu'une appli est utilisatrice des services des libs dont elle dépend) et non quelque chose qui devrait être fortement couplé aux APIs internes.

                  • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                    Posté par  (Mastodon) . Évalué à 4.

                    Tu compares des choses pas comparables. Avoir une API/ABI stable dans le noyau Linux, ce n'est pas anodin, parce que si on veut pouvoir continuer à évoluer, il faut maintenir des couches de compatibilités (un peu ce que fait MS), et donc ça veut dire du travail en plus ! Or, ce travail en plus devrait être assumé par des gens qui n'en ont rien à foutre (ceux qui sont impliqués dans le noyau), et pas du tout par ceux qui sont à l'origine de la demande (parce qu'ils ne s'impliquent pas du tout dans le développement du noyau). Bref, on arriverait à une situation complètement ahurissante de mon point de vue. MS et Apple peuvent se permettre ça parce que des gens paient (et chers) pour que ça soit comme ça. Ce n'est pas le cas dans Linux. Je vais faire mon Zenitram de base : si les entreprises qui demandent ça en avaient vraiment besoin, elles se cotiseraient pour payer quelqu'un pour le faire, mais elles ne le font pas.

                    • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                      Posté par  (site web personnel) . Évalué à 7.

                      elles se cotiseraient pour payer quelqu'un pour le faire, mais elles ne le font pas.

                      http://linuxdriverproject.org/mediawiki/index.php/Main_Page
                      GKH (Greg Kroah-Hartman) propose depuis au moins 2008 le Linux Driver Project avec de l'ordre de 400 développeurs prêts à développer des pilotes libres, sous réserve de disposer des spécification et de la capacité à tester… Voir http://www.linuxjournal.com/content/man-vs-myth-greg-kroah-hartman-and-kernel-driver-project

                    • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                      Posté par  . Évalué à 0.

                      Avoir une API/ABI stable dans le noyau Linux, ce n'est pas anodin, parce que si on veut pouvoir continuer à évoluer, il faut maintenir des couches de compatibilités (un peu ce que fait MS), et donc ça veut dire du travail en plus !

                      Ben oui, c'est pas anodin. Exactement comme pour les bibliothèques userspace, sauf que bizarrement, un certain Linus Torvalds se plaint que l'userland ne stabilise pas ses ABI.

                      Quant au problème du surcroît de travail, on remarquera quand même que le développement de Linux est abondamment financé de nos jours.

                      • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                        Posté par  (Mastodon) . Évalué à 8.

                        Ben oui, c'est pas anodin. Exactement comme pour les bibliothèques userspace, sauf que bizarrement, un certain Linus Torvalds se plaint que l'userland ne stabilise pas ses ABI.

                        L'API/ABI externe du noyau est très stable. On parle des interfaces internes. Faut suivre.

                        Quant au problème du surcroît de travail, on remarquera quand même que le développement de Linux est abondamment financé de nos jours.

                        Abondamment ? C'est pour ça que les amateurs sont souvent parmi les premiers contributeurs en nombre. Et après, est-ce que tu préfères que ces financements aillent à de la maintenance qui ne sert à rien excepté pour des constructeurs qui font de la merde, ou aillent dans de nouveaux développements qui amélioreront le noyau ?

                        • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                          Posté par  . Évalué à -8.

                          L'API/ABI externe du noyau est très stable. On parle des interfaces internes. Faut suivre.

                          Ben oui, faut suivre, abruti. Si tu prenais la peine de suivre, tu aurais remarqué que je parle des modules noyau.

                          Je cite un de mes messages plus haut :

                          """Les applications, non, mais il me semble que cela touche les modules noyau (d'où l'existence de dkms et autres hacks)."""

                          C'est pour ça que les amateurs sont souvent parmi les premiers contributeurs en nombre

                          En nombre de quoi ? De commits ? De lignes de code ?

                          est-ce que tu préfères que ces financements aillent à de la maintenance qui ne sert à rien excepté pour des constructeurs qui font de la merde

                          Bla, bla, bla. C'est à toi de prouver que les modules non-intégrés dans le noyau sont "de la merde". Mais bon, c'est plus facile de jouer un con ("faut suivre", ha ha) que d'avoir des arguments, apparemment.

                          • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

                            Posté par  (Mastodon) . Évalué à 7.

                            Tout d'abord, on n'a pas gardé les cochons ensemble donc tu éviteras les attaques personnelles.

                            Ensuite, tu compares des choses pas comparables et tu te plains. Comparer des «bibliothèques userspace» aux modules du noyau n'a tout simplement pas de sens : l'un est une interface externe, l'autre est une interface interne. Donc si on veut comparer des choses comparables, on compare avec l'interface externe du noyau… qui elle est extrêmement stable.

                            En nombre de quoi ? De commits ? De lignes de code ?

                            «Les hobbyistes occupent comme d’habitude la troisième place (…) Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux.»

                            C'est à toi de prouver que les modules non-intégrés dans le noyau sont "de la merde".

                            Mais ce n'est pas mon hypothèse à moi, hein. Je cite karteum59 : «tous les constructeurs n'adhèrent pas au mode de développement du noyau car pour nombre d'entre eux ça ne vaut pas le coup/coût de se conformer aux exigences de qualité des devs kernel pour faire rentrer leur code dans l'arbre officiel, et donc (au mieux) le bout de code est maintenu sous forme de module externe.» C'est bien de ça dont on parle depuis le début, et c'est pour ceux-là qu'on devrait, selon certains, maintenir une API interne stable.

                            Moi, j'ai appelé ça «faire de la merde». Et j'ai dit que chacun pouvait appeler ça comme il le souhaitait, y compris : «participer de manière positive et responsable au noyau Linux».

                            Donc, je maintiens, il faut suivre la conversation plutôt que d'insulter gratuitement.

            • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

              Posté par  (site web personnel) . Évalué à 4.

              Ca s'appelle la pression de sélection. Il y a ceux qui s'adaptent et il y a les fossiles.

    • [^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »

      Posté par  . Évalué à 5. Dernière modification le 30 octobre 2014 à 12:40.

      One of the things, none of the distributions have ever done right is application packaging […] making binaries for linux desktop applications is a major fucking pain in the ass

      => http://0install.net/
      De rien :)

  • # Un .deb pour les prochaines versions ?

    Posté par  (site web personnel) . Évalué à 0.

    Ça m'effare un peu de voir tout ce que tu as du faire pour que ce soit disponible dans Debian… Même si certaines des demandes sont sans doute justifiées et intéressantes pour un logiciel de la plus haute qualité, ben… zut hein. Puis c'est pas comme si les exigences sur des détails de ce genre améliorait l'expérience de l'utilisateur final (je dis ça, mais c'est aussi parce que je suis un peu fâchée des mises à jour sur ma debian qui ont rendu mon ordi bon pour la casse… merci pulseaudio, ati, cups, systemd, je vous hais…).

    Ce qui explique aussi pourquoi je ne trouve pas les dernières versions de jeux que j'aime bien dans les paquets de ma debian !

    Je comprendrais que tu ne souhaite pas refaire tout le bazar pour les versions suivantes du jeu, mais si tu peux proposer en téléchargement sur ton site un .deb qui "juste marche", ça aidera bien tous les gens qui sont plus doués pour jouer que pour compiler (faut vraiment que je sois dans un bon jour pour me mettre à compiler, et je ne suis pas la seule à fuir ça…). Ce sera moins contraignant que de repasser dans les packages officiels mais ça permet à ceux qui aiment la version qui y est de venir chercher la version la plus à jour et jouer, tout simplement ;)

    • [^] # Re: Un .deb pour les prochaines versions ?

      Posté par  . Évalué à 2.

      des mises à jour sur ma debian qui ont rendu mon ordi bon pour la casse…

      Haha ! Vraiment ? Je suis curieux…

      • [^] # Re: Un .deb pour les prochaines versions ?

        Posté par  . Évalué à -1.

        Systemd qui ne prend plus en comptel a fermeture du couvercle du portable donc surchauffe du processeur et des circuits internes et portable bon pour la casse.

        • [^] # Re: Un .deb pour les prochaines versions ?

          Posté par  . Évalué à 6.

          Le portable est pas supposé s'éteindre tout seul en cas de chauffe trop importante, avant destruction des circuits internes ?

        • [^] # Re: Un .deb pour les prochaines versions ?

          Posté par  . Évalué à 5.

          En même temps, le but de systemd c'est pas d'acceler et simplifier le lancement et l'extinction des processus ? Ici, nous sommes dans un parfait exemple de réussite : le PC meurt plus vite, et en plus c'est plus simple, il suffit de fermer le capot.
          Bref, non, tu ne fais que démontrer la supériorité de systemd vis à vis des autres systèmes de démarrage :)

          -->[]

        • [^] # Re: Un .deb pour les prochaines versions ?

          Posté par  (site web personnel) . Évalué à 5.

          ça a un rapport avec http://xkcd.com/1172/ ? (cité par patrick_g dans le journal suivant)

        • [^] # Re: Un .deb pour les prochaines versions ?

          Posté par  . Évalué à 3. Dernière modification le 30 octobre 2014 à 13:15.

          Systemd qui ne prend plus en comptel a fermeture du couvercle du portable donc surchauffe du processeur et des circuits internes et portable bon pour la casse.

          Euh si il le prend en compte :
          /etc/systemd/logind.conf -> paramètre HandleLidSwitch (qui est par défaut sur "suspend").

          C'est bien pour ça d'ailleurs que je mettais ce paramètre et d'autres sur "Ignore" dans Xfce pour que ce soit géré par xfce4-power-manager. Si systemd le gérait pas par défaut, je me serais pas emmerdé plusieurs fois.

          Depuis que je suis sous KDE, je me souviens pas avoir touché à ce fichier. Soit c'est resté sur ignore (comme je l'avais laissé), soit le gestionnaire d'énergie de KDE spécifie à systemd que c'est lui qui gère (j'en sais rien).

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Un .deb pour les prochaines versions ?

      Posté par  (site web personnel) . Évalué à 4.

      Ça m'effare un peu de voir tout ce que tu as du faire pour que ce soit disponible dans Debian… Même si certaines des demandes sont sans doute justifiées et intéressantes pour un logiciel de la plus haute qualité, ben… zut hein. Puis c'est pas comme si les exigences sur des détails de ce genre améliorait l'expérience de l'utilisateur final

      Si tu penses que la priorité de Debian est la satisfaction de l'utilisateurs, tu oublies quelque chose : en réalité, les priorités de Debian sont les utilisateurs et les logiciels libres, c'est marqué dans le contrat social. L'arbitrage entre ces deux priorités est un sujet important, ceci dit.

  • # Sinon…

    Posté par  . Évalué à -2.

    Si tu ne veux pas avoir affaire aux coupeurs de cheveux en quatre, le plus simple est d’éviter leur distribution.

    À l’opposé, il y a Frugalware, dont les paquets sont aussi simples à faire que pour Arch Linux et qui a de plus la réputation d’accepter facilement les paquets.

    Bon, cette distribution n’a certainement pas (encore ?) le même nombre d’utilisateurs… mais à un certain stade, le jour où un nombre assez important de développeurs feront des paquets pour les distributions plus souples que Debian, il faudra bien que les mainteneurs Debian empaquettent leurs logiciels eux-mêmes pour conserver les utilisateurs de la Debian.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Debian est le nouveau Ubuntu

    Posté par  . Évalué à 10.

    C'est marrant de voir le score de ce journal alors que plusieurs commentaires ont bien démonter la plupart des propos tenus. On préfère taper sur les mainteneurs des distributions avant de se poser des questions. Et après, on se demande pourquoi les distributions manquent de main d'œuvre.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Debian est le nouveau Ubuntu

      Posté par  (site web personnel) . Évalué à 10.

      (Note : Je maintiens des trucs et des bidules dans Debian depuis quelques années, ce qui suit est probablement biaisé.)

      J'imagine que les points abordés dans le journal peuvent expliquer le score :

      • Les mainteneurs sont vus comme très stricts, ce qui est bien dans l'absolu, pas pour ce petit paquet chéri (pour lequel les règles/obligations de la distribution ne sont pas vraiment importantes).
      • La personne qui passe du temps à effectuer la revue du paquet et à formuler des suggestions est vue comme un tyran imposant ses vues personnelles et arbitraires plutôt que comme un sponsor prêt (modulo d'éventuelles itérations) à valider le paquet avec une signature numérique.
      • Le tyran en question est vu comme étant représentatif de l'ensemble du corps des mainteneurs, plutôt que comme un individu au sein d'une communauté. Cela apporterait vraisemblablement un peu trop de nuances de considérer que les suggestions susmentionnées sont personnelles et varient éventuellement d'un mainteneur à un autre.
      • Les mainteneurs passent leur temps à patcher les logiciels et les piles de patches sont perçues comme étant le Mal incarné.

      En fonction du vécu de chacun, cela peut rappeler quelques souvenirs plus ou moins plaisants concernant l'ajout d'un paquet, l'intégration d'un patch, la prise en compte d'une suggestion. Et manifester son ressentiment via un « score » est beaucoup plus facile que se remettre en question et/ou considérer des points de vue différents et/ou contribuer un peu plus, un peu mieux, ou juste différemment ?

      Debian Consultant @ DEBAMAX

    • [^] # Re: Debian est le nouveau Ubuntu

      Posté par  (site web personnel) . Évalué à 10.

      À la première lecture de ce journal, j'étais du coté de son auteur, pensant aussi que les exigences de l'équipe de Debian étaient exagérées, puis à la lecture des commentaires j'ai peu à peu mis de l'eau dans mon vin.

      Néanmoins, je maintiens que le journal est de qualité et son score est justifié, parce que le débat qu'il a provoqué est très intéressant et permet de me faire une idée d'un aspect du logiciel libre que je ne connais pas.

      Tout ca pour dire que le score du journal est représentatif de l'ensemble du journal, et donc sa note élevée est selon moi parfaitement justifiée.

      • [^] # Re: Debian est le nouveau Ubuntu

        Posté par  (site web personnel) . Évalué à 9.

        L'auteur du journal a modifié son point de vue. Voir l'ajout NdM en fin de journal.

        • [^] # Re: Debian est le nouveau Ubuntu

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 29 octobre 2014 à 21:30.

          le placer en intro permettrait de le contextualiser un peu plus :-) en ajoutant une phrase du genre : "les discussions de ce journal ont permis à l'auteur et aux packageurs de faire chacun comprendre leur point de vue, incitant l'auteur du journal a modifier son point de vue".

          Cela permet de faire comprendre que la discussion est souvent^Wparfois enrichissante, plutôt qu'un point de vue tranché : l'empathie permet de converger vers une approche acceptable par chacun, allant dans le sens de l'amélioration (et chacun y apprend quelque chose).

    • [^] # Re: Debian est le nouveau Ubuntu

      Posté par  . Évalué à 5.

      C'est un journal très pertinents vu le nombre de personnes qui ont finalement amélioré leur opinion justement des contributeurs Debian.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Debian est le nouveau Ubuntu

        Posté par  . Évalué à 4. Dernière modification le 30 octobre 2014 à 13:10.

        C'est un journal très pertinents vu le nombre de personnes qui ont finalement amélioré leur opinion justement des contributeurs Debian.

        Mouai, bof. Le journal lui même n'est pas pertinent du tout. Je l'ai plussé, mais après m'être rendu compte qu'on peut le résumer à un gros râleur (pardon) qui se plaint plusieurs mois après les faits parce qu'il est pas fichu de faire la distinction entre "should" et "must" (seule explication possible), ben je l'aurais descendu en flèche, et je pense que je ne suis pas le seul dans ce cas.

        Perso, je n'ai pas une très bonne opinion de Debian à cause de sa lourde bureaucratie et son manque de pragmatisme à un niveau plus "politique", mais je n'ai jamais et de mauvaise opinion envers ses contributeurs et packageurs. Globalement, Debian fait du bon boulot de packaging par rapport à son objectif d'obtenir et de maintenir une version "stable" sur le moyen terme. Le packageur se montre courtois, fait quelques suggestions, bref, fait ce que l'on peut attendre d'un packageur. Au final, mes opinions de Debian et de ses contributeurs n'ont pas changées, tandis que le contenu de ce journal est simplement hors sujet.

  • # Java ?

    Posté par  . Évalué à -5.

    A mon humble avis, tu compiles vraiment du médiocre et ce n'est pas de ta faute, c'est un problème qui vient du langage de programmation (C++ en l’occurrence).

    Si l'on avait fait ce logiciel en Java, les dépendances auraient été incluses dans le jar par une chaine de compilation courte et moderne de type maven et la seule et unique dépendance de l'application ainsi packagée serait alors la JVM.

    Évidemment, la JVM est garante du bon fonctionnement de l'application sur les différentes plateformes…

    Write once, run everywhere c'est pas pour les médiocres.

    • [^] # Re: Java ?

      Posté par  . Évalué à 8.

      Si l'on avait fait ce logiciel en Java, les dépendances auraient été incluses dans le jar par une chaine de compilation courte et moderne de type maven et la seule et unique dépendance de l'application ainsi packagée serait alors la JVM.

      Scénario que tu veux absolument éviter dans un contexte type Debian où toutes les dépendances DOIVENT êtres fournies par un paquet Debian et où tout utilisateur de ces dépendances DOIT utiliser la version empaquetée.

      Évidemment, la JVM est garante du bon fonctionnement de l'application sur les différentes plateformes…

      Ou pas. « Run everywhere » c’est bien plus théorique que pratique dès que tu mets jogl dans l’équation par exemple…

    • [^] # Re: Java ?

      Posté par  . Évalué à 4.

      Si l'on avait fait ce logiciel en Java, les dépendances auraient été incluses dans le jar par une chaine de compilation courte et moderne de type maven et la seule et unique dépendance de l'application ainsi packagée serait alors la JVM.

      Je peux te présenter un certain devnewton< qui t'expliquera ce qu'il pense du packaging à l'aide de maven sous Debian.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Java ?

        Posté par  . Évalué à -5.

        Je ne vois pas ce qu'une solution destinée aux professionnels du métier ait à voir avec une distribution gérée par une communauté d'intégristes barbus.

        Chacun son métier.

      • [^] # Re: Java ?

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 02 novembre 2014 à 19:57.

        J'avais même fait un journal sur le sujet!

        Depuis la situation a empiré:

        • Debian propose un java toujours plus obsolète par défaut (version 6).
        • Apple ne propose plus du tout Java.
        • Je n'ai pas de Windows 8 pour tester, mais je crains le pire…

        Bref je n'ai pas de mots pour dire ce que je pense des éditeurs et des mainteneurs qui œuvrent chaque jour pour pourrir les langages à runtime afin d'enfermer les utilisateurs ou de satisfaire leur idéologie préhistorique et barbu.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Java ?

          Posté par  . Évalué à 3.

          Je n'ai pas de Windows 8 pour tester, mais je crains le pire…

          Les applets Java y tourne encore (péniblement). Donc, j'imagine que ça doit aller.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Java ?

          Posté par  . Évalué à 2.

          Je n'ai pas de Windows 8 pour tester, mais je crains le pire…

          Bah faut télécharger et installer soi-même Java (en déochant un adware au passage si je me souviens bien).

          Bref je n'ai pas de mots pour dire ce que je pense des éditeurs et des mainteneurs qui œuvrent chaque jour pour pourrir les langages à runtime afin d'enfermer les utilisateurs ou de satisfaire leur idéologie préhistorique et barbu.

          T'as plus qu'à passer à .NET/Mono… ;-)

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # caractères spéciaux

    Posté par  (site web personnel) . Évalué à 3.

    Dans la liste des changements que j’ai le droit de remettre à une version ultérieure il y a la présence de caractères latin1 et non ASCII dans le code.

    Je n’ai pas regardé ton code, mais si jamais ton appli est multilingue, il doit être probablement possible de créer un fichier de langue anglaise qui ne contient qu’une seule traduction, la chaîne qui contient le caractère spécial.

    Dans ton code tu écris (C) moi, et dans la traduction tu écris © moi. Celui qui lance le programme avec LANG=C verra « (C) moi », et ceux qui lanceront le programme avec LANG=en_US.UTF-8 (par exemple) ou LANG=fr_FR.UTF-8 verront « © moi ». Non ?

    ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.