Journal Aider au développement d'un nouveau gestionnaire de paquets

Posté par  (site web personnel) .
Étiquettes : aucune
7
4
juin
2009
Bonjour,

Vous vous souvenez peut-être de la dernière fois où vous m'avez vu, quand j'ai présenté Logram, mon projet d'environnement de bureau et de distribution, sur ce site.

Récemment, l'horizon de Logram s'est élargi, en particulier grâce à l'arrivée de visiteurs en provenance de Linuxfr. Nous avons décidé de développer non-seulement un environnement de bureau, mais également une distribution, dont le but est d'intégrer l'environnement de bureau léger de Logram, ainsi que KDE, pour former un tout cohérent et très complet.

C'est de cette distribution dont je vais vous parler, et plus particulièrement de son gestionnaire de paquets. En effet, nous avons décidé de ne pas utiliser RPM ou DEB, mais bien notre propre gestionnaire de paquets, qui vise à combler les manques de ces deux gestionnaires, ainsi que d'autres qui peuvent exister.

Fonctionnalités du gestionnaire de paquets

Setup, car ce gestionnaire s'appelle comme ça, permet entre autres de gérer aussi bien des paquets sources que des paquets compilés. Par exemple, en tant que développeur, vous ne devez que renseigner les étapes de compilation d'un paquet, et ses dépendances à la compilation. C'est tout, les utilisateurs peuvent l'installer.

Quand un utilisateur compile un paquet, il crée des paquets binaires, qui peuvent être renvoyés sur le serveur de Logram, pour en faire profiter toute la communauté. Pour éviter le gros problème de sécurité que vous avez normalement remarqué (n'importe qui peut envoyer un paquet infesté de virus ou totalement cassé), des validateurs et empaqueteurs vérifient le paquet, aidés par un système de hash.

Cas d'utilisation

Prenons un exemple. Marie télécharge les sources de kdebase-apps-4.3.0. Elle les compile sur une architecture amd64, et envoie le paquet. Marc fait de même, mais modifie le paquet en ajoutant un trojan. Jérémy compile également ce même paquet, et l'envoie (propre celui-là).

Du côté des validateurs, ils voient arriver deux paquets avec le même hash, et un dont le hash est totalement différent. Ils vont donc se dire que quelque-chose ne vas pas avec le paquet dont le hash n'est pas bon, et vont le vérifier (en environnement chrooté, sécurisé et tout et tout). Ils vont voir qu'il y a un problème avec le paquet, et pour être sûr, ils vont tester ceux de Marie et de Jérémy.

Une fois les paquets validés, ils arrivent dans le dépôt incoming de Logram (ça vous rappelle pas une autre distro ce nom ?). Les utilisateurs peuvent alors l'installer directement en version binaire, sans devoir compiler, et testent. Au bout d'un certain temps sans problèmes remontés, c'est que le paquet est bon, et il arrive dans main, où tous les utilisateurs peuvent l'utiliser.

Ce système n'est pas parfait, car il nécessite des validateurs, tout n'est pas automatique. De plus, un hash est changé dès que le moindre bit d'un fichier est modifié, donc si quelqu'un compile le paquet sur une machine un peu différente, ça ne marchera pas. C'est pour cela qu'il faut trouver une méthode de hashage qui permette de voir si un paquet est un peu ou beaucoup différent d'un autre.

Le but de cette utilisation est de mettre la communauté au premier plan. Ceux qui viennent de Windows vont être plongés dans le développement Libre et communautaire assez rapidement, et vont passer de «J'installer des programmes crackés ou payés très cher, avec des formats fermés, et pas de mises à jour» à «J'installe des paquets produits par d'autres utilisateurs, et rigoureusement testés, et quand j'en ai besoin, je peux créer mes paquets et les partager».

État du développement

Il y a quelques jours, la version 0.0.0-1 de Setup est sortie. Cette version n'était qu'une version preview, ne permettant pas d'installer un paquet. Samedi, la version 0.0.0-2 sortira (vous l'aurez deviné : on sort une version par semaine, une version par mois, une autre tous les 6 mois, et une version majeure quand c'est prêt). Elle permettera enfin d'installer un paquet, et de générer le paquet binaire assorti (pas encore envoyable sur le serveur).

Pour la version 0.0.0-3, j'espère pouvoir implémenter la suppression d'un paquet, et peut-être d'autres détails (paquets installés en ligne de commande (déjà implémenté dans la bibliothèque utilisée), versions, cache, etc). Début juillet, la version 0.0.1-0 sortira, quoiqu'il arrive. Normalement, pour la fin des vacances ou le début de l'année prochaine (année scolaire), on aura une version 0.1.

Développements parallèles

Le gestionnaire de paquets n'est pas le seul projet sur lequel travaillent les membres de Logram. On a également un gros projet de site web, la quatrième version, qui permettera entre autres d'avoir sous la main tous les outils nécessaires à la vie de la distribution (gestion des paquets, des demandes, des rapports de bugs, de la communauté, etc).

Une distribution n'est pas seulement un gestionnaire de paquets. Il faut aussi "Logrammiser" KDE. C'est une tâche qui n'est pas spécialement complexe, mais assez longue. Elle consiste à empaqueter KDE pour Logram, en l'adaptant (configuration, changement de quelques artworks pour rappeler le site, intégration des outils Logram).

Le gestionnaire de paquets lui-même est très important, car Logram vise les utilisateurs venant de Windows, et on leur a beaucoup venté les mérites d'un gestionnaire de paquets. Logram veut leur donner ce qu'ils attendent. Ainsi, nous avons au programme :

  • La ligne de commande Setup pour les fans de console et les sysadmins
  • pkgUi, installateur graphique de paquets. Je ne sais pas comment implémenter cela. J'ai pensé à une kio-slave qui renvoie des formulaires HTML à afficher dans Konqueror. Ainsi, si vous cliquez sur une url de type "package://nom_du_paquet", ça installe le paquet dans une belle GUI. Ça peut aussi être un kpart
  • pkgAssistant, créateur graphique de paquets depuis les sources. Ainsi, si un paquet ne se trouve pas dans les dépôts, pas même les sources, il suffit de télécharger les sources et de lancer l'assistant. J'ai déjà codé un tel assistant, mais pas adapté à Setup (il était tout de même capable de détecter le type de système de construction utilisé, de configurer le paquet, de trouver ses dépendances, de le compiler et de l'installer)

Un autre projet assez important, mais je ne sais pas s'il va continuer, est LoCoM, pour Logram Configuration Manager. C'est en gros un programme qui lance des scripts basés sur un fichier UI de Qt Designer et un fichier XML contenant des scripts Qt Script. Ce langage n'est pas une copie du XUL (qui utilise du xHTML et du Javascript), mais bien un langage plus adapté aux fichiers de configuration. Ainsi, on pourra trouver plein d'interfaces graphiques de configuration sous Linux, sans trop d'efforts pour le développeur (une belle UI prend 1h à développer en LoCoM, et presqu'un jour en compilé normal).

Logram a besoin d'aide

Vous voyez que Logram a plein de projets ambitieux, dont le but n'est pas d'être nombriliste, mais bien d'aider le Libre. Un but avoué mais qu'on ne crie pas sur les toits, définis dans cette news est de sortir Logram à une date assez proche de celle de la sortie de Windows 7. Je pensais avant, mais vu que Windows sort en Octobre, je ne veux pas prendre le risque de sortir quelque chose de mal fini. La raison est que cette sortie va provoquer beaucoup de bruit autour de Windows et de MS, et que c'est à ce moment que les moyens de pression de MS sont les plus faibles (les constructeurs qui hésitent entre XP, Vista et Seven, les utilisateurs de même, les critiques qui fusent). Bref, on pourra facilement dire «Vous connaissez Seven, vous allez adorer Logram», et sur Logram, mettre des liens vers toutes les distribs Linux (je ne veux pas que Logram deviennent un MS-like qui masque la concurence, tant que les utilisateurs sont libres, je suis content).

Logram a donc besoin de contributeurs, qui seront très bien accueillis. Tout le monde peut participer, il suffit d'avoir un peu de bonne volonté :

  • Bien sûr, comme le dit le titre, il faut des gens pour s'occuper de Setup lui-même. Les fonctionnalités à coder dans les prochains jours sont assez simple à implémenter, et en plus, Logram est 100% documenté en français, à cette adresse (pour la bibliothèque qui s'occupe des paquets, seule bibliothèque parfaitement documentée pour le moment).
  • Des graphistes, pour créer les artworks de la distribution, mais on a encore tout le temps.
  • Des packageurs (sortes de sysadmins). La création de paquets pour Setup est détaillée dans le lien vers la documentation que je donne plus haut. Vous trouverez aussi de l'aide dans le dossier doc/ du dépôt SVN que je vous donnerez.
  • Des webmasters. La v4 du site de Logram va être longue à coder. Si vous avez du temps libre, que vous maîtrisez PHP et l'utilisation du framework Symfony, alors vous pouvez m'aider

Me joindre

Si vous sentez que vous pouvez faire quelque-chose pour Logram, ou si vous avez la moindre remarque, envoyez un mail à steckdenis at logram-project point org. Si vous voulez, vous pouvez aussi vous inscrire sur le site et poster dans les forums. Seulement, sachez (je ne fais que prévenir) que la communauté actuelle est composée de jeunots de 14~17 ans en provenance du Site du zéro, qui ne brillent pas tous par leur maturité (quelques microsoft's fanboys, d'autres pour les macs, d'autres super-noobs qui demandent comment compiler un code C++, etc).

Si vous avez l'âme de bêta-testeur, vous pouvez essayer la mailing-list de Logram, qui est encore assez expérimentale (elle tient depuis un mois, mais qui sait (de plus, les logs ne marchent pas)).

Si vous êtes plutôt "discussion directe", vous pouvez aller sur le channel #logram-project sur FreeNode, mais je n'y suis pas souvent, et on y parle assez souvent de plein d'autres choses que de Logram (maturité de la communauté oblige).

Merci de m'avoir lu.
  • # Contributeur régulier?

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

    Juste par curiosité, est-ce que tu as déjà contribué à des projets open-sources?

    Réinventer les mêmes solutions avec quelques variations est un des maux des logiciels libre. Plutôt que de tout recréer depuis zéro, ne serait-il pas plus profitable à l'ensemble de la communauté si ces changements étaient proposé dans dpkg/rpm.

    Je ne pense pas que les développeurs de dpkg/rpm soient beaucoup plus con que toi, ils apprécieront toute amélioration bien écrite. Et de ton coté tu profiteras de toute les solutions aux problèmes qui ont été résolu par eux.
    • [^] # Re: Contributeur régulier?

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

      J'y avais pensé, mais deb, rpm et les autres sont soit binaires, soit sources.

      Ici, c'est sources ou binaire. Par exemple,


      setup --install llibs:source


      compile les bibliothèques de Logram et les installe. Si les paquets binaires sont disponibles,


      setup --install llibs:binary


      installe les binaire.

      Ensuite, d'autres distributions utilisent bien leur propre gestionnaire de paquets, donc pourquoi pas Logram ?
      • [^] # Re: Contributeur régulier?

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


        Pour construire automatiquement le paquet lorsqu'il est téléchargé, ajoutez seulement -b à la ligne de commande, comme ceci :

        $ apt-get -b source nomdupaquet

        à l'intérieur du répertoire créé pour le paquet après le téléchargement. Pour installer le paquet construit par la commande ci-dessus, vous devez directement utiliser le gestionnaire de paquets, comme ceci :

        # dpkg -i fichier.deb
      • [^] # Re: Contributeur régulier?

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

        Je me rends compte que je n'ai pas totalement répondu à la question.

        Oui, je compte participer à un projet libre. Je connais les sources de KDE quasi par coeur, et ait déjà proposé des améliorations. Dès que j'en aura l'occasion, je pourrai proposer des patchs.

        De plus, je suis en ce moment en train d'étudier les sources de Wormux, son créateur ayant dit qu'il manquait de contributeurs. Je compte essayer d'implémenter l'IA, et de corriger quelques bugs de la version SVN (dont certaines très gênants).

        Pour rejoindre ce que j'ai dit dans mon précédant message, Setup est totalement différent de RPM par exemple. Son proncipe de fonctionnement n'est pas le même, et de plus, je relève un très gros inconvénient à ces deux gestionnaires de paquets : c'est monstrueusement complexe de créer un paquet DEB, ainsi que RPM (pour avoir testé les deux). Setup propose aussi des fonctions intéressantes, permises par le format XML utilisé. Voici un exemple de fichier XML d'un paquet.

        Setup gère par exemple :

        - les téléchargements depuis des fichiers de l'arbre, depuis un dépôt, depuis un site externe, et depuis un SCM (git, SVN, etc), ainsi que la méthode "embed" utile pour les petits patchs (le contenu du fichier est inséré dans le lbuild)
        - créer un paquet est extrêmement simple, même quand il est complexe (USE flags, dépendances en fonction des USE flags, téléchargements multiples, informations de construction, scripts personnalisés, etc).
        • [^] # Re: Contributeur régulier?

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

          >>> Je connais les sources de KDE quasi par coeur

          Moi je dis balaise....ou bien foutaise ?
          • [^] # Re: Contributeur régulier?

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

            Pas par coeur, mais je sais où tout se trouve, et je sais ce que les fichiers contiennent. En ayant développé Logram, je me suis de temps en temps inspiré de KDE.

            Donc oui, je sais me retrouver dans trunk/KDE/kdelibs/kdecore, et aussi dans kdeui. J'ai déjà jeté un oeil dans kio, mais pas encore dans kjs et khtml (je ne vois pas ce que je ferais de ça). J'ai quelques fois exploré kdevelop et kdesdk (pour voir comment parchait Kate). J'ai aussi assisté à la migration de Konversation depuis branches/work à trunk/extragear. Grand moment :) .

            Enfin bon, j'avoue que mon terme était un peu fort. Je m'y retrouve on va dire.
        • [^] # Re: Contributeur régulier?

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

          J'ai fait des paquets debian de chose simple et c'est simple... Par ailleurs, si tu as un 'make install', checkinstall te fait un paquetage ! Certes, tout cela ne fait pas des 'beaux' paquetages mais ce sont des paquetages qui marchent bien et je peux faire facilement mon livecd debian avec.

          Il y a des centaines de développeurs debian, notamment en France, qui développent et font des paquetages. Ces personnes développent sous svn, git, etc. Il y a des outils dans debian pour suivre tout cela et rendre le boulot le plus facile possible. Je suis sur que ces personnes seraient prêtes a te donner un coup de main pour passer le cap des premiers paquets.

          Combien d'heures as tu prévu sur ta distrib et ton gestionnaire de paquetage ? Si tu veux que Logram soit diffusé, combien d'heure une personne devra passer sur tes sources pour adapté les méthodes debian sur ton cas ? Car rassures moi, ton objectif est que Logram soit quand même dans les distributions à base de debian et de fedora ?

          Au final, n'est-il pas plus simple de travailler en équipe et de "débaucher" un DD !
        • [^] # Re: Contributeur régulier?

          Posté par  . Évalué à 2.

          Wormux est un projet intéressant, néanmoins Hedgewars est aussi un clone de Worms, de plus ils utilisent Qt4 pour le GUI, cela devrait t'intéresser, surtout que personnellement je trouve Hedgewars plus jouable que Wormux.
        • [^] # Re: Contributeur régulier?

          Posté par  . Évalué à 1.

          As tu regardé du coté d'arch linux et d'AUR?

          Ca me semble ressembler à ce que tu proposes :
          Pkgbuild : un manière très simple de concocter un pacquet
          pacman : sources et/ou binaires précompilés
          Choix entre la version supportée et la version communautaire (pour les paquets supportés officiels : tous les paquets d'AUR ne sont pas supportés).

          J'avais trouvé ça génial... mais bon dieu que c'est long la compilation.
      • [^] # Re: Contributeur régulier?

        Posté par  . Évalué à 6.

        Après cela, il suffira de refaire la libc et linux, et ça devrait vous satisfaire ;-)

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Contributeur régulier?

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

      Pitié, oui, ne pas faire un nième paquetage !!!

      A l'heure ou certains travaillent à unifier les procédures de paquetage (à défaut des paquetages eux-meme), surtout ne rajoute pas un nouveau truc !

      http://www.packagekit.org/

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Contributeur régulier?

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

        Un front-end PackageKit est tout à fait envisageable, surtout que PackageKit dispose lui-même d'une GUI qui me plaît beaucoup, et très bien intégrée à KDE (sous Kubuntu 9.04, directement dans SystemSettings).

        Seulement, on ne pourra pas avoir toutes les fonctionnalités de Setup, comme on n'a pas toutes les fonctionnalités des paquets deb et autres.

        Néanmoins, je suis pour cette intégration, car, comme pas mal de monde, j'ai toujours trouvé que le manque d'homogénéité est un gros problème pour l'adoption massive de Linux (une distrib ne marche pas comme une autre, et ça déroute les gens qui sont habitués à trouver du Windows chez tout le monde).
  • # Pacman ?

    Posté par  . Évalué à 10.

    Euh, les gars, un gestionnaire de paquet marchant avec des binaires et dont les utilisateurs peuvent créer eux-même des paquets, les compiler et les envoyer à des validateurs, ça ressemble fortement ( pour ne pas dire c'est scrupuleusement la même chose ) que pacman, Aur et le dépôt community d'archlinux.

    Pacman a un long développement derrière lui qui lui ont permit de se doter de fonctions utiles ais complexes ( téléchargement des paquets depuis plusieurs miroirs de façon transparente, patch delta ). Pourquoi vouloir réinventer la roue ?
    • [^] # Re: Pacman ?

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

    • [^] # Re: Pacman ?

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

      Je suis entièrement d'accord pour dire que Pacman est très bon, et l'avantage du libre est d'ailleurs que je peux aller rechercher dedans ce qu'il peut manquer à Setup.

      Seulement, utiliser une technologie externe qui a prouvé son efficacité, c'est très bien, mais en créer une autre, différente, et adaptée à nos besoins, c'est mieux.

      Par exemple, Setup pourra reprendre des éléments de Pacman, et peut-être que pacman pourra reprendre des éléments de Setup, si le besoin s'en fait ressentir.
      • [^] # Re: Pacman ?

        Posté par  . Évalué à 7.


        Seulement, utiliser une technologie externe qui a prouvé son efficacité, c'est très bien, mais en créer une autre, différente, et adaptée à nos besoins, c'est mieux.


        Prouve-le !
        • [^] # Re: Pacman ?

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

          Il y a deux écoles :

          - ceux qui veulent intégrer tout ce qu'on trouve de bon. Pas mal de distribs le font (basées sur Deb ou sur Rpm)
          - ceux qui veulent quelque-chose qui convient à leur besoin, comme Gentoo et son Portage, et surtout ArchLinux qui a l'air si plébiscité ici. Si ArchLinux avait repris Deb, est-ce que son gestionnaire de paquets si aimé serait né ?

          Bref, reprendre l'existant est bien, mais si on croit pouvoir faire mieux, autant essayer non ? Si on n'y arrive pas, tant pis. Si on y arrive, alors tout le monde est gagnant :) .
          • [^] # Re: Pacman ?

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

            Certes. Alors dans ce cas, je te souhait de réussir de faire mieux que tous les autres réunis. :)
            • [^] # Re: Pacman ?

              Posté par  . Évalué à 1.

              Je ne sais pas s'il y arrivera mais je pense que ça vaut la peine d'essayer, et surtout que dans le libre c'est possible .....

              En effet les divers gestionnaires de paquets existant ont tous des avantages et des inconvénients les uns par rapport aux autres. On dispose donc d'une base de code permettant de recréer rapidement un gestionnaire de package "tout neuf" reprenant tout ces avantages. De plus le fait de repartir de zero permet de pouvoir plus facilement supprimer les inconvénients que l'on se traine sur un gestionnaire particulier ... Enfin un oeil neuf peut parfois faire du bien ... Au pire si ça ne prend pas, je suis sur que les autres gestionnaires de packages pourront reprendre des idées ou du code pour l'intégrer chez eux.
              • [^] # Re: Pacman ?

                Posté par  . Évalué à 2.

                Je pense qu'il est plus utile de se baser sur de l'existant et de le modifier à sa sauce que de partir de rien. Ça peut éviter des erreurs de sécurité commis par les autres.

                « 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: Pacman ?

            Posté par  . Évalué à 5.

            si je peux me permettre une petite remarque, avec un nom ultra générique tel que "setup", cela ne risque pas de décoller beaucoup. Supposons que Logam devienne aussi populaire que Archlinux (on peut rêver), on a donc des milliers d'utilisateurs qui vont avoir besoin de "setup" pour gérer leur distribution. Mince, un problème arrive, on recherche sur internet des résultats pour "install setup" "troubleshooting setup", tu penses que cela aidera beaucoup les gens ?

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: Pacman ?

              Posté par  . Évalué à 3.

              En même temps, avec Archlinux, tu as le choix entre des résultats qui te parles un monsieur tout jaune et un truc qui est bon pour ton corps et se voit à l'extérieur.

              « 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

  • # Hum,

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

    En effet, nous avons décidé de ne pas utiliser RPM ou DEB, mais bien notre propre gestionnaire de paquets, qui vise à combler les manques de ces deux gestionnaires, ainsi que d'autres qui peuvent exister.

    tu peux expliquer les manques des rpm et des deb ?

    M.
    • [^] # Re: Hum,

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

      Généralement, à part PacMan (pour aussi répondre au commentaire plus haut), un gestionnaire de paquets est soit binaire (RPM, DEB, même si on peut tout de même récupérer les sources, mais il n'est pas fait pour ça), soit source (portage, et les ports des BSD).

      Ici, Setup a l'avantage de coupler les deux, permettant d'installer des paquets de manière transparente, qu'ils soient sources ou binaires. La même ligne de commande, en changeant juste une option, permet de compiler un paquet au lieu de prendre celui qui existe déjà.

      De plus, tout ceci est couplé à un système de USE flags à la Gentoo, pour les binaires (options de compilation) et les sources (sous-paquets ou options).

      Sinon, je suis entièrement d'accord pour dire que les gestionnaires de paquets existants sont déjà quasiment parfait.
      • [^] # Re: Hum,

        Posté par  . Évalué à 3.

        > Généralement, à part PacMan (pour aussi répondre au commentaire plus haut), un gestionnaire de paquets est soit binaire (RPM, DEB, même si on peut tout de même récupérer les sources, mais il n'est pas fait pour ça), soit source

        TssTss ! Pisi[1] permet de faire les deux, ce que ne fait pas pacman d'ailleurs. Pacman ne fait que du binaire, c'est makepkg qui fait le boulot de compilation et d'empaquetage à l'aide de fichiers PKGBUILD relativement faciles à aborder.

        Pisi est un superbe outil, par contre la construction des « recettes » est contraignante (xml + utilisation d'un framework python).

        [1] http://www.pardus.org.tr/eng/projeler/pisi/index.html

        The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

        • [^] # Re: Hum,

          Posté par  . Évalué à 1.

          Je ne sais pas si cela a changé depuis, mais je trouvais Pisi extrêmement lent (des Pardus installées il y a un et 2 ans).
          C'était encore pire pour son utilisation avec l'interface graphique et ce, même avec des ordinateurs récents.
          Je serai très heureux d'apprendre que ça c'est amélioré :)
      • [^] # Re: Hum,

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

        En vrac, tu gères comment la compat d'ABI, le fait que 3/4 des upstreams ne savent pas bump-er un soname correctement pour pas que le système soit en vrac à toutes les mises à jour ?

        M.
      • [^] # Re: Hum,

        Posté par  . Évalué à 1.

        Pour ma part, je suis fan du système de paquet PBI utilisé par PC-BSD.

        http://fr.wikipedia.org/wiki/PC-BSD_Installer
      • [^] # Re: Hum,

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

        Alors pourquoi dépenser ton temps et ton énergie dans un projet qui ne fait pas mieux ?

        Prends pacman, ou mieux yaourt, contribues y, ce sera sans doute bien plus productif. À mon humble avis, y aurait des choses à faire au niveau de la gestion des licences, sous archlinux y a un tas de paquet qui sont marqué «custom», qu'il soit libre ou pas. Là c'est plus un soucis de remplir correctement les metadonnées. Mais même correctement remplie ce serait bien de pouvoir lister/supprimer les logiciels par licences, histoire d'être sur de pas avoir de logiciel proprio.
      • [^] # Re: Hum,

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

        >> un gestionnaire de paquets est soit binaire (RPM, DEB, même si on peut tout de même récupérer les sources, mais il n'est pas fait pour ça), soit source (portage, et les ports des BSD).

        Un commentaire dit soit la vérité, soit n'importe quoi.

        Les ports d'OpenBSD sont binaires.
        Les ports de FreeBSD sont sources
        Les packages de NetBSD sont sources
        Les ports de FreeBSD et les packages de NetBSD servent à la compilation automatique de binaires qu'on peu gérer avec les mêmes outils.


        Conclusion: Tu connais rien aux gestionnaires de logiciels, et tu vas immédiatement décider d'utiliser les ports de FreeBSD ou le pkgsrc car ça a été pensé par des gens bien pour des gens bien, et que c'est bien.
  • # Mon rêve...

    Posté par  . Évalué à 3.

    si seulement on pouvait avoir un emerge qui permet la configuration de USE avec les binaires... voir avec les optimisations CPU en prime \o/

    Ne devrions nous pas réinventer un format de binaire où seraient incluses les instructions preproc afin de customiser les binaires à l'installation ?

    Allez, une autre idée, un version de (g|c|wtfyw)make qui crée directement un paquet installable et où il n'y aurait plus qu'à choisir les options à activer/désactiver lors de l'installation !

    Qui a dit qu'il était difficile d'installer un package source quand il va directement installer les dépendances nécessaires (et pas lors du ./configure où tout un tas de saloperies seront installées), se configurer, se compiler demander les options et s'installer dans la config demandée via un simple double click ?

    Bon... tu codes ou je code ? :)
    • [^] # Re: Mon rêve...

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

      C'est déjà codé :-° :


      setup --install llibs:binary --uses -panache-plugins,+tests


      n'installe pas les plugins Panache contenus dans le paquet binaire llibs (et ne les télécharge même pas).


      setup --install llibs=devel:source --uses -kde,+tests


      Télécharge depuis le dépôt SVN le code des bibliothèques Logram, les compile avec les USE flags sélectionnés, et installe le tout. Dans /tmp/lgrpackages/llibs_pkg, il y a un fragment de lbuild ainsi que les archives binaires compressées en LZMA qui sont prêts à l'envoi :) !


      pkgassistant --console /le/chemin/d'un/Makefile/CMakeLists.txt/autre


      À venir, mais construira le paquet d'un répertoire contenant les sources (ma version de dev réussi à compiler X-Moto !). Il suffit de retirer "--console" pour avoir une magnifique GUI. J'ai une vidéo de 40 Mio à envoyer, si quelqu'un la veut.
      • [^] # Re: Mon rêve...

        Posté par  . Évalué à 2.

        Ce que je voulais dire pour les binaires, c'était plutôt d'avoir un seul paquet binaire comprenant toutes les options, et qui pourrait être divisé en fonction des besoins.

        un peu dans le genre

        0010100100100110000
        #ifdef with-plugins
        100100101001
        #endif
        10010010111010100


        Grâce par exemple à un nouveau mode de gcc qui sortirait un fichier de découpe du code par fichier (si nécessaire)....

        Tout ça pour éviter 25 compilations du même code, un seul téléchargement pour tester les 15 use différents, etc...

        Bref, un petit brin de folie ;)

        Mais bravo pour le travail accompli, va vraiment falloir que je teste ... promis, je reporterai plus !
  • # Liens

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

    Oups, je me rends compte que j'ai oublié les liens, je suis désolé.

    - http://www.logram-project.org, pour le site de Logram, qui permet d'avoir un aperçu de Setup


    svn co svn://logram-project.org/logram/branches/work


    pour obtenir le code de la version de développement de Setup (le trunk contient encore uniquement le DE, en attendant que Setup soit fonctionnel, et qu'il rejoigne le trunk).
  • # Amusant ...

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

    Amusant de voir cette agressivité envers ce journal !
    Cette personne arrive en disant "je veux faire qq chose" et il se retrouve avec une troupe de barbus qui lui expliquent qu'il ne faut rien faire.
    Même si ça existe déjà, même si c'est proche de certaines choses, il a son idée et son courage pour essayer.
    Je suis pro-deb mais je ne vais pas lui demander d'utiliser les .deb parce que j'aime ca ...

    mes 2 centimes (de francs) à moi !
    • [^] # Re: Amusant ...

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

      Non je pense plutôt que c'est le fait que c'est trop en un coup.

      Je me contenterai de faire d'abord un environnement de bureau, le faire devenir populaire, le faire le plus complet possible. Alors après peut être des distribs vont le packager et peut être le proposer en environnement d'installation. D'avoir des traductions, etc....

      Et alors une fois que le truc tourne, je vais créer ma distrib maintenir les nombreux paquets, voir même recréer un gestionnaire de paquets.

      Bref en gros j'attendrai que ça prenne un peu avant d'attaquer sur tous les fronts. Je pense pas que tu as autant de contributeurs que KDE/Gnome ou compagnie donc je mettrai plutôt tes ressources (en nombre limités) sur son projet de base Logram, l'environnement de bureau.

      A partir sur tous les fronts, tu fais pas les choses a fond et bien surtout avec un nombre réduit de contributeurs. Il est facile de tomber dans le trop gros que tu peux plus maintenir.

      C'est aussi mes 2 centimes. Mais ca reste une bonne initiative son Logram, l'environnement de bureau.
      • [^] # Re: Amusant ...

        Posté par  . Évalué à 2.

        Bref en gros j'attendrai que ça prenne un peu avant d'attaquer sur tous les fronts.
        Il me fait penser à un certain NS ..
    • [^] # Re: Amusant ...

      Posté par  . Évalué à 3.

      La question n'est pas tant d'aimer ou pas.
      Le problème, c'est que refaire sans arrêt la même chose dans son coin n'est pas constructif.

      Après, le programmeur est roi, si il veut développer à partir de zéro, c'est son droit. Si des concepts et idées intéressantes en sortent, tant mieux, le libre en sortira grandit.

      Mais, le risque est grand que ça fasse un énième projet abandonné faute de développeur quand il s'en lassera, alors qu'il pourrait s'assoir et améliorer de l'existent et largement supporté. Surtout en matière de gestionnaire de paquet, où le moins qu'on puisse dire et que l'offre est foisonnant.

      Pourquoi repartir de zéro quand il existe un tas de projet à côté qui font quasiment la même chose, qu'on peut librement patcher et qui ont réellement le désir d'intégrer des patchs ?
  • # Le Francais te tuera...

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

    Je viens de checkouter le code comme je pense qu'on te l'as deja dit, si tout les commentaires sont en Francais ça n'ira pas.

    Tu perds trop de contributeurs comme çà. Et tu perds les contributeurs hardcore allemand hélas :(.

    Ta base de code n'est pas encore énorme il est temps de le changer.
    • [^] # Re: Le Francais te tuera...

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

      C'est prévu. Le README est en anglais, mais je vous déconseille franchement de le lire tellement l'anglais y est horrible.

      D'ailleurs, si quelqu'un se sent le courage de traduire, je veux bien qu'il essaie. Malheureusement, je ne suis pas dans la possibilité de coder en anglais (foutue éducation en Belgique, ça fait près de 10 ans qu'on nous apprend le flamand, et seulement deux ans on on a un peu d'anglais).

      Sinon, normalement, la version 4 du site sera en anglais, de même pour le code, etc.
    • [^] # Re: Le Francais te tuera...

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

      Je viens de jeter un coup d'œil au code aussi. Je suis d'accord que les commentaires en Français c'est une très mauvaise idée. Il y a même un mélange d'anglais et de Français.

      On voit dans le code que tu manques de l'expérience qu'on acquiert sur des projets comme KDE.

      Quelques remarques en vrac sur ce que j'ai vu:
      -tu ne respectes pas les conventions de codage de Qt et KDE (http://techbase.kde.org/Policies/Kdelibs_Coding_Style). Pourquoi se donner du mal?
      -il y a beaucoup de code franchement dégueulasse comme:
      QHttp::ConnectionMode mode = murl.scheme().toLower() == "https" ? QHttp::ConnectionModeHttps : QHttp::ConnectionModeHttp;
      Quand tu contribues à un gros projet comme KDE, tu t'arranges pour que le code soit bien lisible pour la review. Tu pourrais apprendre pas mal de chose grâce à ces reviews
      -beaucoup de commentaires sont inutiles. Des commentaires plus généraux sur des blocs de code sont plus intéressant que des commentaires qui dit ce que fait la ligne qui suit.
      -le design des classes est parfois bancal.

      Je pense que tu gagnerais vraiment a participer à un projet open-source. Si tu contribue à Qt ou KDE, du code comme celui que j'ai vu serais rejeté. MAIS tu apprendrais a améliorer ton code et le patch suivant serait mieux.
      • [^] # Re: Le Francais te tuera...

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

        Je sais, je ne respecte pas les conventions de codage, mais c'est parce qu'elle ne me conviennent pas.

        Je suis plutôt pour un code très aéré, donc avec des tabulations de 8 caractères, des accolades à la ligne, etc. Ce n'est pas parce qu'on utilise Qt qu'on doit suivre ses conventions de nommage, qui sont jolies, mais parfois difficiles à lire.

        Pour le code que tu montres, avec QHttp, ben justement, c'est le seul morceau de copier/coller de la doc de Qt, dans un des exemples qu'ils donnaient, donc ce morceau n'est pas de moi.

        Pour les commentaires, oui, il y en a énormément, mais ils ont l'avantage de vraiment montrer mon raisonnement, car à la base, je les écrits pour me fixer les idées. Ainsi, quand les gens viennent, ils comprennent le code rapidement. J'ai eu l'occasion de me plonger dans le code de Plasma, et je peux te dire que j'aurais vraiment, mais vraiment aimé avoir plus de commentaires. La doc de cette partie de l'API est très succinte, et les commentaires secs. Bref, avec tous ces DesktopCorona et autres, j'ai du tatoner pendant près d'une semaine pour arriver à un truc qui marche de mon côté.

        Pour le design des classes, j'avoue. La classe Package contient tout ce qui touche au fichier XML des paquets, sa sous-classe Private tout ce qui ne doit pas être exposé à l'extérieur (et tu remarqueras que je suis la convention du pointeur d ici, comme quoi j'en suis capable). Effectivement, la classe PackageSystem est boiteuse, avec des fonctions statiques et d'autres non. J'ai essayé d'en mettre quelques-unes en statique, pour permettre de facilement faire un "PackageSystem::package(nom, version, méthode)" sans avoir besoin d'une instance (et donc d'un pointeur d en mémoire, ainsi quele classe private, et tout un QObject).

        La classe Util est vraiment tordue, je l'avoue. Son but premier est de fournir des méthodes qui ne sortent pas de libpackages, comme download() (méthode qu'on retrouve, statique, dans PackageSystem).

        Si tu trouves encore du code que je peux améliorer, dis-le, et je me ferai un plaisir de le corriger. En attendant, je vais regarder de bien plus près le code de KDE, pour apprendre.
        • [^] # Re: Le Francais te tuera...

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

          > Je suis plutôt pour un code très aéré, donc avec des tabulations de 8 caractères, des accolades à la ligne, etc.

          oué enfin c'est pas parce que tu met l'accolade à la fin d'une ligne que tu peux pas passer de ligne là où c'est nécessaire.

          Par contre spa méchant mais du code avec des tabulations de 8 j'oublie direct... (et si c'est codé en français encore plus...)

          Et faire ces propres conventions de codage c'est bien mais varier à ce point ... ben heu, c'est pas pour rien que les conventions sont souvent assez proche (accolade mise à part)
        • [^] # Re: Le Francais te tuera...

          Posté par  . Évalué à 2.

          En fait tu decris ici meme pourquoi tes projets vont foirer.

          a) Ils reinventent la roue et amenent peu de nouveaute (tu dis toi-meme que deb/prm sont quasi-parfaits)
          b) Ils demandent une adaptation a des conventions sorties de nulle part

          Il y a des choses qu'on retrouve dans la plupart des projets a succes (informatiques ou pas ) :

          a) Avancee significative
          ou
          b) Avancee sans plus, mais sans effort d'adaptation necessaire ou tres peu


          Tu n'as aucun des deux.
          • [^] # Re: Le Francais te tuera...

            Posté par  . Évalué à 2.

            c) arriver à faire croire que ton logiciel est ce dont on a besoin et que tu es le seul à pouvoir offrir ces fonctionnalités
            d) un gros paquet d'argent et une grosse campagne de publicité (mensongère ?)

            Le gros paquet d'argent, c'est pour les avocats et politiciens, cela va de sois...

            Puis si tu as suffisamment de succès, tu pourrais aussi demander aux autres distributions d'arrêter de distribuer des autres DE si ils veulent pouvoir distribuer logram. Ca aidera à garder le monopole...
          • [^] # Re: Le Francais te tuera...

            Posté par  . Évalué à 3.


            a) Ils reinventent la roue et amenent peu de nouveaute/.../
            b) Ils demandent une adaptation a des conventions sorties de nulle part


            Et pourtant en partant sur des principes similaires, on a vu ce qu'est devenu Windows, alors, qui sait ? ;)

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Des idées pour logram

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

    Avec le coup du menu circulaire, il pourrait être intéressant de développer une approche «une fenêtre, un document», et plutôt que d'avoir des logiciels dans le menu, avoir des outils utilisables avec tous les documents (ou grisés).

    Qu'en pensez-vous ?
    • [^] # Re: Des idées pour logram

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

      Bonne idée, mais il y a un problème : qu'est-ce qu'on fait des applications non-Logram ?

      Par exemple, FireFox gère les onglets, et n'exposera pas à Logram une méthode pour savoir ce qu'on peut faire avec un document ouvert dedans. Ça obligerait Logram à recoder toutes les applications pour les intégrer, et c'est une tâche monstrueuse.

      Je retiens tout de même, au cas où quelqu'un trouve une solution.
      • [^] # Re: Des idées pour logram

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

        Effectivement, ça demande des applications conçues pour bien s'intégrer. Cela dit tu n'es pas obligé de tout recoder. Tu peux par exemple utiliser webkit pour le rendu de pages html.

        Les onglets devraient être géré par le gestionnaire de fenêtre.

        En fait avec cette approche «une fenêtre, un document», l'utilisateur ne devrait pas avoir à ce soucier du principe d'application ou de format de fichier. On se rapproche plus de l'analogie avec le bureau physique, on a des feuilles de papier, et les outils dont on à besoin à coté.
  • # le kernel

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

    quel est le noyau ds ta distrib ?
    C est l occasion d en develper un nouveau..
  • # Dispersion d'efforts ?

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

    Je trouve le projet Logram intéressant : même si je ne l'utilise pas et ne pense pas m'y mettre sérieusement, j'y ai jeté un coup d'œil et je trouve sympathique d'avoir un nouvel environnement de bureau basé sur Qt, plus simple qu'un GNOME ou un KDE. L'enthousiasme de ses développeurs me semble communicatif.

    Ensuite, le projet de distribution Logram avec l'environnement de bureau par défaut, ça me semble encore logique. Il aurait pu se baser sur une autre distribution existante.

    Mais le développement d'un nouveau gestionnaire de paquets ne risque-t-il pas de porter atteinte au développement de l'environnement de bureau ? C'est un type de logiciel qui reste malgré tout assez complexe, et qui vous obligera à maintenir vous-même une arborescence de paquets source. Donc très coûteux en temps !
    • [^] # Re: Dispersion d'efforts ?

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

      En fait, la question intéressante est de savoir combien il y a de personne avec mister steckdenis pour gérer tout cela ?

      A vu de nez, je suis d'accord, il faut finaliser et maintenir Logram avant de papillonner si on n'est pas assez nombreux. Pour gérer un parc conséquent de machine avec de multiple OS, le maintien dans le temps de quelque chose est TRES couteux en énergie.
      • [^] # Re: Dispersion d'efforts ?

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

        Tiens, j'ai pris le dépot subversion de Logram. Oui, je sais, c'est un autre projet.


        ~/logram/sources # svn log | grep '^r[1-9]' | wc
        152 2128 11085

        ~/logram/sources# svn log| grep '^r[1-9]' | grep -v steckdenis | wc
        5 70 345


        Sur les 5 commits qui ne sont pas de steckdenis, il se cache deux personnes...

        Un autre petit lien sur une discusion sur les langages

        http://www.logram-project.org/fr/node/319

        Comme beaucoup d'autres personnes, si vous ne souhaitez pas que votre projet finisse comme votre LogramOS et que votre environnement de bureau mette moins de temps que E17 ou Perl6 a se finaliser, dispercez-vous un peu moins. Vous n'avez pas la communauté de Perl6 ni les appuis derrière (ni (encore) les compétences).
        • [^] # Re: Dispersion d'efforts ?

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

          wow
        • [^] # Re: Dispersion d'efforts ?

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

          Bref c'est ce que tous le monde dit, steckdenis tu es pleins de bonne volonté mais finissons l'environnement de bureau logram et après on verra pour un gestionnaire de paquetage, une distrib, un kernel, un langage, un compilateur (parce que gcc pue), une nouvelle archi processeur.

          Fais nous un truc polish, récolte des gens motive, bâti une vrai communauté de contributeurs et la suite ira toute seule. Comme KDE, comme Gnome comme n'importe quel projet opensource.


          Bah oui quoi faut pas le décourager non plus. Si le truc me plait alors j'irai peut être coder dessus (enfin sans les tab a huit espaces sinon je vais être oblige de paramétré mon Qt Creator exprès pour Logram, ou alors on fait un IDE Logram, non je me disperse....).
  • # dépendance

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

    Dans toutes ces histoires de paquet, y'a pas un truc d'oublié ? la gestion des dépendances par exemple, non ?
    Et c'est pas juste une table ou une liste hein, souvent derrière ça y'a des algos, des dépendances plus ou moins forte. Si tu veux une résolution rapide c'est pas simple non plus, si tu veux aussi les installer dans le bon ordre, etc
    A voir aussi lorsque des logiciels ont des dépendances vers des versions différentes (mais pas forcément incompatible non plus...)
    m'enfin tout ça pour dire que personne n'en parle et que sans ça ton système de paquet ben il marchera pas bien (et c'est vrai, si on compare chez mandriva c'est pas du ressort de rpm mais de urpmi, chez debian c'est pas deb mais apt-get/aptitude - si je ne me trompe pas)
    • [^] # Re: dépendance

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

      Comme je l'ai demandé dans un commentaire ou je n'ai pas eu de réponse, ça ne tient pas compte de pas mal de questions inhérentes au packaging : la compatibilité binaire, et que packager une librairie un peu complexe demande un peu plus qu'un simple make install.

      M.
      • [^] # Re: dépendance

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

        Les dépendances sont gérées, à plusieurs niveaux (obligatoires, recommandées, conflits). Les dépendances peuvent dépendre d'une "USE string" (donc une chaîne qui indique les conditions de USE, comme par exemple "machin,-chose", pour quand machin est activé ou que chose ne l'est pas).

        Les dépendances sont installées dans l'ordre données dans le lbuild. Les dépendances binaires sont installées avant les sources (pour éviter qu'une compilation plante), etc.

        J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct (peut-être pas le meilleur, mais il est viable). Je ne le montre pas dans mes exemples car je n'ai pas un deuxième paquet (j'ai juste llibs pour le moment, et pas Qt par exemple).

        Pour la compatibilité binaire, un paquet peut dépendre d'une version exacte d'un paquet, ou d'une version supérieure/inférieure. Pour les grosses bibliothèque, il y a un système de scripts et de patchs de disponible. Je dois avouer que je n'ai pas encore beaucoup pensé à ça.
        • [^] # Re: dépendance

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

          > J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct

          Juste parce que je pense que c'est des choses comme ça qui font que les gens n'ont pas forcément confiance / ne croient pas en ton projet :

          C'est pas parce que tu as mis une semaine entière que c'est bien.
          Tu peux très bien faire de la merde toute ta vie, comme bien concevoir / coder en général, le temps n'a que peu d'influence et dépend aussi (beaucoup) de l'expérience acquise.

          Je pense par exemple que tu minimise _beaucoup_ le problème de résolution de dépendance, qui est au contraire au coeur d'un gestionnaire de paquet

          Par exemple, si tu lis http://fr.opensuse.org/Libzypp/Gestion_des_paquets il y a le passage suivant :
          En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.

          Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.

          (l'emphase est de moi)

          Voici les notes correspondantes :
          # [1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
          # [2] http://en.wikipedia.org/wiki/Computational_complexity_theory
          # [3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
          # [4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006


          La manière dont tu réponds montre justement que tu n'as pas ce qu'il faut pour résoudre correctement les dépendances, dans un temps correct (installer, faire des tests sur 2 - ha non, 1 - paquet ne prouve strictement rien est est vraiment un cas particulier hyper simple)
          • [^] # Re: dépendance

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

            j'oubliais un commentaire sur le passage cité : si apt a des grosses lacunes, alors qu'il fonctionne depuis des années, a nécessité pas mal de taff (plus d'une semaine) etc, je doute que ce soit tout seul comme ça en une semaine que ça marche.
            La résolution des dépendances moi comme ça, sans trop réfléchir, ça me fait plutôt penser à de la Theorie_des_graphes ce qui est un poil plus complexe que d'avoir une bête liste de dépendances
            • [^] # Re: dépendance

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

              Setup n'a que quelques semaines, et sa gestion des dépendances est encore toute simple. Seulement, quand je donne une durée, c'est pour dire que je n'ai pas codé ça vite fait, j'ai un minimum réfléchit.

              Pour le moment, j'utilise l'algorithme le plus simple qu'il puisse exister :


              Quand on installe un paquet :
              on obtiens sa liste de dépendances directes (format "paquet" ou "paquet=version" ou "paquet>=version", etc)
              Si l'utilisateur le veut, on ajoute aux dépendances la liste des recommendations.
              On a donc une simple liste de chaînes, qu'on explore.
              Pour chaque chaîne :
              --Si le paquet n'est pas installé:
              ----Parser sa chaîne, pour obtenir le nom du paquet, sa version à installer, et sa méthode d'installation (données, binaire ou source)
              ----Ajouter le paquet à la liste (ce qui appelle cette fonction, qui est donc récursive)
              Quand l'ajout des paquets est fini, on ajoute ce paquet à la liste des paquets à installer. Ainsi, les dépendances sont installées avant ce paquet, ce qui est logique


              C'est tout simple, et ça marche pour la majorité des paquets. Je n'ai pas cité la dedans l'élimination des dépendances.

              Une fois la liste des paquets à installer/supprimer construite, elle est affichée à l'utilisateur, qui peut la valider ou pas (dans la version graphique, il pourra peut-être la modifier).

              Ensuite, la liste est procédée : les paquets sont installés dans l'ordre, donc d'abord les dépendances, puis les paquets sélectionnés.

              Si vous avez des conseils, ne vous privez pas.
              • [^] # Re: dépendance

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

                Si tu as A qui dépend de B en version 1.0
                A étant installé (donc B aussi en 1.0)

                C dépend de B en version >= 1.0 <= 1.5

                Tu installes C, ça roule

                Maintenant D est créé avec comme dépendance A et B en version > 1.0
                Comment tu fais ?
                Si tu installe D, il faut A qui lui veut B=1.0 mais D veut B>1.0
                s'il existe un A supérieur venant avec B>1.0 alors tu peux t'en sortir
                Par contre, si cette version de A vient avec une version de B=1.6 il faut supprimer C par exemple

                m'enfin c'est un exemple moisi, bateau, et pas précis, mais ça touche seulement le début de tes problèmes
                lorsque tu aura un nombre conséquent de paquet tu sera bien obligé de jeter ton modèle et d'en faire un vrai, par contre nécessitant beaucoup plus de taff que ça...

                Va lire par exemple la note 3 que j'ai mise plus haut
                • [^] # Re: dépendance

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

                  Ah oui, effectivement, ça devient bien plus complexe. Je n'avais pas pensé à vérifier qu'une installation/mise à jour casse des paquets.

                  Là, ça change tout. Je vais m'empresser de lire ce document.
                  • [^] # Re: dépendance

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

                    C'est ca le problème... Tu te lances dans des projets énormes sans vraiment avoir vérifié. Alors effectivement, comme certain ici on un peu de bouteille (mais aimerait être plus jeune), ils sont sceptiques !

                    Donc, un gestionnaire de paquet, c'est pas un truc qui se fait à l'arrache.

                    Plus bas, comme tu le dis, ton algo de comparaison de paquet binaire légèrement différent ne marche pas. Que crois-tu, s'il y avait un truc simple, les logiciels anti-virus l'utiliserait tous ! Faire un logiciel anti-virus est un truc dur, très dur.

                    Bref, encore une fois, met de coté ta propre distrib à base de ta propre gestion de paquet. Concentre toi sur Logram et utilise les paquets debian qu'on t'as fait et debianlive pour faire ta distrib Logram. Ca fout un coup au moral mais au final, tu seras aussi content qu'Olivier Fourdan.

                    Et quand tu en as marre de coder sur Logram, participes à d'autres projets pour améliorer ton savoir sur tel ou tel sujet.
  • # Magie !

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

    >> Du côté des validateurs, ils voient arriver deux paquets avec le même hash

    Ah oui ?
    Car ils ont le même compilateur, les mêmes de compilation options, la même entropie qui fait que les algos non déterministes donnent les mêmes valeurs ?

    Je suis désolé, mais là, il y a faute grave en mathématiques. Ton truc ne marchera pas.
    *En revanche*, tu peux décider de créer un réseau de confiance si tu le souhaites, mais t'est pas prêt de distribuer du code certifié de toute façon…
    • [^] # Re: Magie !

      Posté par  . Évalué à 3.

      Et dans le même genre :

      C'est pour cela qu'il faut trouver une méthode de hashage qui permette de voir si un paquet est un peu ou beaucoup différent d'un autre.

      Au contraire, les fonctions de hachage essaient de vérifier la condition (ou effet) d'avalanche : en modifiant 1 bit en entrée chaque bit de sortie à une probabilité 1/2 d'être modifié (et donc "beaucoup différent" du précédent).
    • [^] # Re: Magie !

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

      tu peux expliquer ? où interviennent les algos non deterministes dans la construction d'un paquet ?
      • [^] # Re: Magie !

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

        C'est en effet bien plus complexe, mais le journal était déjà conséquent. De plus, ce système est prévu pour dans très longtemps, donc j'ai encore le temps d'y réfléchir. Je suis ouvert à toutes suggestions.

        Une méthode qui peut être utilisée est la génération d'une image. Par exemple, chaque pixel a comme valeur le checksum d'un bloc de donnée. Ainsi, un cerveau humain peut très facilement voir si une image est proche d'une autre, ou pas, alors que comparer deux longs hash, c'est bien plus complexe.

        Pour le réseau de confiance, on aurait à nouveau le problème relevé plus haut dans les commentaires : il faudrait énormément de monde pour maintenir les paquets. Avec ce système «Les utilisateurs envoient leur paquets», il ne faut plus trop de monde pour créer les paquets, juste des personnes qui s'occupent de créer les lbuilds sources (et de les tester, mais ils ne doivent le faire que sur une architecture), et les utilisateurs pourront créer leurs lbuilds sources eux-même (avec pkgAssistant, comme dit dans la news).
        • [^] # Re: Magie !

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

          >> Une méthode qui peut être utilisée est la génération d'une image. Par exemple, chaque pixel a comme valeur le checksum d'un bloc de donnée. Ainsi, un cerveau humain peut très facilement voir si une image est proche d'une autre, ou pas, alors que comparer deux longs hash, c'est bien plus complexe.

          C'est nul. Le but du hash, c'est l'EXACTITUDE !
          Deux hash qui se ressemblent mais son juste un peu différents, moi, j'installe pas le logiciel !
          Le problème de la complexité du hash, c'est que t'as pas compris à quoi ça sert, ni comment ça marche (et pire ! Tu montres que tu veux faire exactement ce que le commentaire ironique à qui tu répond craignait !)

          Deux programmes avec un seul bit de différent auront (par "effet avalanche") un hash complètement différent. On VEUT ce comportement, et des gens passent des ANNÉES pour prouver qu'un algo de hash fait bien ça.


          Enfin, le réseau de confiance, il demande pas de mainteneurs, il demande des utilisateurs. Si tout le monde fait confiance à Alice, alors moi aussi je peux faire confiance à Alice.
          Si personne ne connait Bob^WBernard(^^), alors je demande aux gens autour de moi s'ils ont eu des soucis avec ses logiciels. Point barre.


          >> De plus, ce système est prévu pour dans très longtemps, donc j'ai encore le temps d'y réfléchir.
          Haa tout s'explique ! Tu fais le gestionnaire de logiciels de Hurd !
          • [^] # Re: Magie !

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

            Non non, je but de ce "hash" n'est pas de signer les paquets, ou de les vérifier pour l'utilisateur, c'est pour vérifier que deux paquets (soit-disant les mêmes) envoyés par deux personnes ne sont pas trop différents.

            Dans le journal, je donne l'exemple d'un trojan inséré dans un paquet. On a trois paquets : deux quasi-semblables, et un différent. Avec des images, on peut voir lequel est différent, et l'éliminer.

            Bien sûr, une signature GPG et un hash (un vrai hash) sont utilisés une fois le paquet validé et placé dans les dépôts, bien entendu.
            • [^] # Re: Magie !

              Posté par  . Évalué à 7.


              --- GOOD 2003-11-05 13:46:44.000000000 -0800
              +++ BAD 2003-11-05 13:46:53.000000000 -0800
              @@ -1111,6 +1111,8 @@
              schedule();
              goto repeat;
              }
              + if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
              + retval = -EINVAL;
              retval = -ECHILD;
              end_wait4:
              current->state = TASK_RUNNING;


              Tu penses que les "hash" des deux paquets kernels GOOD et BAD se ressembleraient ? Plus ou moins que les binaires du même code source compilés avec des compilateurs ou des optimisations différentes ?

              Tu me fais penser à un certain Jayce...
            • [^] # Re: Magie !

              Posté par  . Évalué à 2.

              Et si je change la valeur d'un entier pour introduire un buffer overflow, tu vas voir a l'oeil nu la différence de 0.4% du canal alpha sur un pixel ?
              • [^] # Re: Magie !

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

                Je réponds aux deux commentaires :

                Soit une image de 256x256, donc de 65536 pixels. On peut donc s'en servir pour représenter des fichiers de minimum 196k (trois octets par pixels). pour les fichiers plus petits, on réduit l'image, pour les plus grands, on place plusieurs octets par pixels (on ne fait que les additionner bêtement, pas besoin de plus).

                Les composantes R, G et B de chaque pixel sont les valeurs des octets qu'ils représentent. On sauve l'image. On a donc une image gribouillie par fichier, et on ne sait rien en faire.

                Maintenant, pour chaque image, on prend les images des autres fichiers, et on fait leur moyenne, puis la différence avec l'image du fichier. On obtiens donc ... une image toute noire pour un fichier concordant !

                Si le moindre octet, ou groupe d'octets ne correspond pas, de jolis et brillants pixels de couleurs vont apparaître sur l'image.

                Avec les optimisations du compilateur, on peut avoir un léger bruit sur les images, bruit qu'on peut laisser passer. Si jamais une ligne de code, comme montrée dans le commentaire plus haut, est modifiée, ce ne sera pas quelques octets de changés, mais une quarantaine.

                Au lieu d'avoir quelques (ou plus) pixels différents éparpillés sur l'image, on aura une "tache" plus claire. La quantité de pixels ne fera donc pas la différence (une image peut être bruitée), mais plutôt leur disposition. Si une zone de pixels contigus sont clairs, c'est qu'il y a un problème.

                On applique donc un petit flou, puis quelques autres opérations, et enfin un ajustement du constraste, et on peut obtenir de belles images avec des taches quand ça ne va pas, ou toutes noires quand ça va.

                Je m'en vais tester tout ça, pour vérifier mes dires. (et ça, ce sera un bon petit logiciel libre qui va pouvoir servir à tout le monde, j'aurai au moins créé un comparateur rapide de fichiers binaires :P ).
                • [^] # Re: Magie !

                  Posté par  . Évalué à 6.

                  C'est émouvant comme un chaton qui pose ses petites papates sur une plaque vitrocéramique en toute innocence.

                  Je t'offre un billet d'avion pour le blackhat à Vegas si tu veux présenter ton idée.
                  • [^] # Re: Magie !

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

                    Effectivement, ça ne marche pas. Les images sont tout à fait brouillées dès que je change une option de compilation, et le changement d'une ligne est imperceptible.

                    Il va malheureusement falloir tester tous les paquets, ou encore trouver une autre solution (ou alors ne pas proposer l'envoi de paquets, mais ce serait perdre quelque-chose de très pratique (autant d'architectures que d'utilisateurs de supportées)).
                    • [^] # Re: Magie !

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

                      Oh j'ai trouvé, comment ais-je pu ne pas y penser.

                      La GPL et la LGPL demandent qu'on distribue les sources avec les binaires, du moins quand on modifie. Tous les paquets ne sont pas GPL, mais on peut s'aider de cette demande.

                      Quand un paquet est créé par Setup, les binaires sont placés dans /tmp/lgrpackages/paquet_src. Les sources qui ont construit ce paquet se trouvent dans /tmp/lgrpackages/paquetversion_src.

                      Il "suffit" de réempaqueter les sources et de les joindre aux paquets binaires. Elles seront aussi envoyées au serveur, et comparées avec les sources "officielles". Si elles ne sont pas les mêmes, on fait un diff, et si le patch est intéressant, on l'applique aux sources officielles.

                      Pour que ce soit un minimum secure, il faut éxécuter les actions dans cet ordre (le but est d'empêcher l'éventuel cracker de modifier les sources avant, pendant ou après la compilation/création du paquet) :

                      - l'archive source est téléchargée, puis décompressée. On calcul un md5 de l'archive tar obtenue
                      - les fichiers de l'archive sont décompressés dans /tmp/lgrpackages/paquetversion_src (le cracker a déjà perdu ses modifs ici ^^ )
                      - un md5 de toutes ces sources est calculé (avec un re-tarage), et comparé au premier.
                      - Si les hash ne correspondent pas, on quitte tout
                      - On stocke le timestamp actuel
                      - On compile le paquet
                      - On supprime tous les fichiers plus récents que le timestamp actuel (la compilation ne modifie normalement pas de fichiers source, mais c'est à vérifier).
                      - On recalcul le md5 des sources, et on recompare
                      - Si ce n'est pas bon, on quitte tout
                      - le recalcul aura créé une archive tar. On la compresse en lzma, et on l'envoie avec le paquet, ainsi que le hash du tar non-compressé.
                      - sur le serveur, le hash envoyé est comparé avec le hash des sources officielles décompressées.
                      - si le hash ne correspond pas, on refuse le paquet.

                      Normalement, pas moyen de passer outre :) . Quelques questions maintenant.

                      > Pourquoi calculer les hash sur des archives tar non-compressées ?

                      On doit calculer pas mal de hash ici, et un md5sum (ou sha256sum) est bien plus rapide qu'un passage par lzma ou bzip2. De plus, les sources officielles sont normalement en lzma, mais peuvent aussi être en bzip2, z, etc.

                      > Comment faire pour SVN ?

                      La séquence est assez simple (et s'applique aussi à git et autres) :

                      o svn checkout
                      o calcul du md5
                      o svn log doit être vide
                      o calcul du md5

                      Les deux md5 doivent être les mêmes, sinon ça veut dire que l'utilisateur a modifié des fichiers. De plus, l'emplacement des dépots SVN récupérés est placé dans /var/setup/cache/hash_sha_du_nom_du_dépot. Ainsi, un script malicieux a plus de mal à détecter et à modifier le dépot.


                      Malheureusement, tout cela ralentit vraiment fortement la création de paquets, et ne devrait donc être activé que quand l'utilisateur veut envoyer son paquet.

                      De plus, étant open-source, le pirate pourra très facilement modifier Setup pour faire sauter la protection. Malheureusement, la GPL v3 interdit de placer un code de vérification dans Setup qui l'empêche de démarrer s'il a été modifié.

                      Problème hyper épineux.
                      • [^] # Re: Magie !

                        Posté par  . Évalué à 4.

                        Je suis sur qu'en lançant une quête, on peut même t'avoir un billet en business.

                        T'es pas sérieux au moins ?
                        • [^] # Re: Magie !

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

                          Je cherche, c'est tout. Celui qui ne cherche pas ne trouve pas. C'est peut-être impossible, auquel cas je ne trouverai jamais, mais comme je tiens un tant soit peu à mes idées, j'essaie de les rendre réalisable.

                          Généralement, on ne se moque pas des gens qui cherchent à arriver à leurs fins.

                          En clair, je dois arriver à sécuriser cet envoi, d'une manière ou d'une autre. Tout ce que je trouve, tout ce que je dis est suceptible d'aider des gens qui cherchent la même chose ou quelque chose de proche. Par exemple, détecter les infimes modifications d'un fichier permettrais de créer de très bons antivirus ou autres programmes.
                          • [^] # Re: Magie !

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

                            Tu cherches à faire un gestionnaire de paquetage, pas un logiciel antivirus. Une chose importante est l'orthogonalisation des tâches. Surtout ne pas tout mélanger.

                            Ton problème est un faux problème. Si la distrib a suffisament de succès, tu auras des serveurs de build automatique comme debian en a et le problème est réglé. Si ta distrib reste a un petit cercle de personne, un réseau de confiance de type gpg suffit et les personnes upload leur paquet. Pas besoin que 300000 personnes upload leur paquet non plus.

                            Bref, a mon sens, ton gestionnaire de paquet ne doit pas gérer un problème organisationnel. C'est pas pour rien que chez debian, il y a des outils différents pour chaque tâche.
                            • [^] # Re: Magie !

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

                              Effectivement, tu n'as pas tort.

                              Setup crée son paquet pour le moment, mais ne l'envoie pas. Je ne vais surtout pas supprimer ceci, mais plutôt le garder pour les fameux serveurs de compilation, et les personnes de confiance (quoiqu'à un moment, je comptais me baser sur un processus 100% communautaire pour assez rapidement avoir en beaucoup d'architectures les paquets de beaucoup de programmes dans les versions les plus récentes).
                          • [^] # Re: Magie !

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

                            >> Celui qui ne cherche pas ne trouve pas. C'est peut-être impossible, auquel cas je ne trouverai jamais, mais comme je tiens un tant soit peu à mes idées, j'essaie de les rendre réalisable.

                            Le truc, c'est que *moi* et d'autres, là, on *sait* que le code auto certifié c'est un domaine de recherche très complexe. Il faudrait de toute façon que tu patches GCC comme un fou pour embarquer des invariants de code dans ton binaire. Et si je ne met pas en doute tes compétences en codage, permet moi de mettre en doute tes compétences en informatique théorique et en maths.
                            On veut pas détecter des infimes modifications, on veut détecter que la sémantique est préservée. Et ça, c'est une autre paire de manches (sinon, "diff" est un très bon antivirus. Bon, il marche que sur les fichiers déja infectés et n'aide aucunement à la prévention, mais bon…)
                        • [^] # Re: Magie !

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

                          Il n'a pas vraiment réfléchis... Je crois qu'il faut laisser reposer le sujet. La, on entre dans le n'importe quoi.
                          • [^] # Re: Magie !

                            Posté par  . Évalué à 3.

                            On dirait limite jayce presentant multideskos...
                      • [^] # Re: Magie !

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

                        $ cat toto.c
                        #include <stdio.h>
                        #include <stdlib.h>

                        int main (int argc, char *argv[]){
                        return 0;
                        }
                        $ make toto
                        cc toto.c -o toto
                        $ md5sum toto
                        8a517cfc4a76ce44d43de253b2aa45ee toto


                        Tu vérifies chez toi aussi ?
                        Si c'est pas pareil, c'est qu'on a du pirater ta version de toto. Formate vite !
                        • [^] # Re: Magie !

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

                          Merde ! Ma version de toto a été piraté ....

                          phoenix@ks354416:/tmp$ cat toto.c
                          #include <stdio.h>
                          #include <stdlib.h>

                          int main (int argc, char *argv[]){
                          return 0;
                          }
                          $ cc toto.c -o toto
                          $ md5sum toto
                          9369f8c6f84f837af9f472d6020b7739 toto


                          J'ai lancé le formatage et vous tiens au coura
      • [^] # Re: Magie !

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

        Dans le *contenu* du paquet.

        Ton binaire peut-être compilé avec des optimisations qui dépendent d'un choix arbitraire.
        Exemple ? Allocation de registre. On choisi *un noeud parmi ceux* de degré le plus élevé. Choix abitraire non déterministe. Et rien ne dit non plus que t'auras le même résultat en compilant "pareil" sur une machine 32 bits ou sur une 64 bits en passant -m32 à GCC.
        • [^] # Re: Magie !

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

          Effectivement, oui.

          Il faut donc trouver un moyen de détecter les grosses différences entre deux fichiers, ou alors en se basant sur la taille (un trojan a toujours un certain poids).

          Ce que vous n'avez pas relevé mais que je n'ai pas dit est la gestion des USEs, qui influence encore le paquet. Bien évidemment, on ne compare que des paquets qui ont les mêmes USE.
  • # Des noms !

    Posté par  . Évalué à 4.

    ton projet ne peut pas marcher !

    tu cites Marie, Marc et Jérémy...
    tout le monde sait que dans la vraie vie ils s'appellent Alice, Bernard et Charles ! (et c'est Bernard le méchant)

Suivre le flux des commentaires

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