Journal Projet Saevia - Recherche de contributeurs

Posté par  .
Étiquettes : aucune
12
14
août
2010
Bonjour à tous,

Avant d'entrer dans le vif du sujet, je tiens à vous présenter en quelques lignes le Projet Saevia, afin que vous sachiez de quoi il retourne exactement...

Saevia, c'est une très petite distribution GNU/Linux qui a pour principal objectif de fournir en plus de l'image ISO habituelle une documentation permettant aux utilisateurs intéressés de créer leur propre ébauche de distribution « à partir de rien », dans le même genre d'idées que LFS, mais en français, et quelque peu plus simple.

Le projet s'appuie sur quelques outils légers, tels que BusyBox ou un gestionnaire de paquets indépendant basé sur celui du Projet SliTaz qui est écrit en bash.

Pour plus d'informations, je vous renvoie naturellement sur la page du projet : http://saevia.org

Aujourd'hui, et bien malheureusement, le projet avance très lentement, dans le sens où je n'ai pas beaucoup de temps à lui consacrer, et parce qu'il manque des contributeurs pour faire avancer le projet.

Par exemple, et c'est d'ailleurs là le but de ce petit journal, je suis à la recherche d'un ou plusieurs codeurs C afin de réaliser, bénévolement naturellement, un gestionnaire de paquets dans le langage.
Je m'explique, non pas que l'actuel ne convienne pas, mais je souhaite documenter à terme toutes les parties de Saevia, allant du gestionnaire de paquets à l'installeur.
C'est pourquoi garder un gestionnaire de paquets en bash n'a pas grand intérêt, et je souhaite poser toutes les bases importantes du projet avant de poursuivre son développement.

Alors, j'ai évidemment quelques notions de C, mais j'ai bien peur de « coder salement » et de m'embourber, alors qu'au contraire, dans un but pédagogique, il faudrait un code extrêmement simple pour pouvoir le commenter au maximum.

Si vous êtes intéressés, je donne quelques détails, le projet n'a pas besoin d'un gestionnaire de paquets de l'envergure de yum ou de pacman (ArchLinux), mais qui soit juste capable d'effectuer les fonctions principales, comme l'installation, la suppression et la mise à jour des paquets tout en gérant les dépendances, le reste est superflu.
Dans le même ordre idée, les dépendances doivent être les moins nombreuses possibles, si seuls glibc et wget étaient requis, ce serait l'idéal...

Voilà, si cela vous intéresse, voici mon adresse mail : info AT saevia DOT org

Aussi, j'attends tout commentaire ou critique me permettant d'améliorer au possible le projet, je vous invite donc à lire le documentation et à présenter vos retours d'expérience sur notre forum...

Je remercie d'avance toutes les âmes charitables qui veulent bien user de leur temps libre à aider un petit projet qui peine, qui peine...

Bien cordialement,
Nicolas

  • # Pourquoi ?

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

    Pourquoi utiliser ou contribuer à Saevia plutôt qu'à ROCK Linux ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 7.

      Parce que l'appel à contribution est fait par un développeur de Saevia qui à exposer ces objectifs dans ce journal ?

      • [^] # Re: Pourquoi ?

        Posté par  . Évalué à 10.

        Peut être que c'était une vraie question du genre "les objectifs de rock linux me semblent similaires et plus avancés, si je ne me trompe pas, pourquoi tu choisis de lancer un projet similaires plutot que de contribuer à l'existant et recréer la roue? Merci de ta réponse, et merci pour ton travail!"
        Et là, le gars de saevia peut expliquer les différences de son projet s'il y en a ou dire "ah merrrrrdeuuu! je savais pas" ou "m'en fous, je fais ce qui me plait, je suis un rebelz qui aime tout refaire from scratch, lorenza lama powa!"?

        • [^] # Re: Pourquoi ?

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

          La question est effectivement intéressante et bien plus générale... je suis en train de discuter avec un mec de linuxfr qui voudrait lancer un projet :
          http://linuxfr.org/~niniryoku/30050.html

          Et on discute des avantages inconvénients à participer à un projet déjà existant... et c'est pas aussi simple que cela. ça peut être un différent à cause d'un langage de programmation ou d'une librairie utilisée que l'on ne maitrise pas. On peut aussi avoir l'impression d'avoir plus de liberté en créant un nouveau projet from scratch... mais je crois que c'est surtout la difficulté de s'intégrer dans un projet qui tourne déjà... réussir à comprendre ce qui manque dans le projet et ce qu'on pourrait lui apporter...

          Et souvent, pour pouvoir faire ces améliorations et propositions d'amélioration, il faut connaitre l'existence du projet en question, mais aussi l'utiliser suffisamment pour savoir si telle ou telle fonctionnalité peut être intégré au projet ou au contraire doit être utilisée à côté.

          Axel

  • # Pas Pacman ?

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

    le projet n'a pas besoin d'un gestionnaire de paquets de l'envergure de yum ou de pacman

    Pacman n'est pas très évolué (surtout comparé à yum, zypper, urpmi, apt...) et ne contient que quelques lignes de C. Peut-être qu'au contraire il pourrait être une bonne base.

  • # SteckDenis

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

    Steckdenis, journaleur régulier ici même, a codé un gestionnaire de paquets en C++ par lui même, en utilisant QT Core comme librairie de support.

    Je ne sais pas si ça correspond à tes attentes, mais ça peut probablement t'intéresser!

    • [^] # Re: SteckDenis

      Posté par  . Évalué à 3.

      Ça risque de faire beaucoup de dépendances non ?

      Une ébauche de gestionnaire de paquet ça n'existe pas quelque part en libre ?

      • [^] # Re: SteckDenis

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

        Il suffit de prendre les versions de 0.X d'un gestionnaire en C déja existant, tu va avoir ton ébauche :p

    • [^] # Re: SteckDenis

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

      Ohoh, on parle de moi sans que je l'aie demandé :D .

      /me se dégonfle les chevilles

      En effet, Nuclear m'a envoyé un mail il y a bien longtemps pour me faire part de son intérêt pour Setup, bien qu'il n'était pas encore très avancé (spoiler : il l'est maintenant, avec un front-end graphique, gestion propre des fichiers, serveur de construction, et 22 669 SLOC, journal dans à peu près un mois).

      Le problème est qu'il veut limiter les dépendances, ce que je peux comprendre. Passer un paragraphe complet à expliquer ce que fait une fonction Qt est un peu trop.

      De plus, Setup est devenu un bon gros morceau, très riche en fonctionnalités et en petit détails, et assez solide (on peut même aller jusqu'à taguer un fichier pour qu'il ne soit jamais remplacé lors d'une mise à jour, y compris s'il n'a pas encore été installé).

      Néanmoins, et heureusement pour Nuclear, la partie «difficile» de Setup, à savoir le gestionnaire de dépendances, et très facilement dé-C++-ifiable. Il est grosso-modo codé en C pur, avec des listes chainées (qui utilisent new à la place de malloc(), mais ça se change facilement), et quelques goodies de base du C++ (classes pour la structure, enums dans les classes, et c'est tout). Il pourra donc facilement le récupérer, puis tenter d'expliquer comment marchent 1601 lignes (sans compter le .h) où chacune d'entre elle a son importance, pour former un solveur à hypergraphe, optimiseur (passes d'optimisations comme en compilation, pour retirer ce qui n'est pas nécessaire) et capable d'attribuer un poids à chaque noeuds et chaque chemin (un beau morceau algorithmique ça, surtout quand on connait la complexité effrayante des hypergraphes).

      Sinon, je dois bien encore avoir quelque-part un petit morceau de Setup 1 (l'actuel est le 3), un petit hack tout simple codé en un week-end, qui utilise Qt, wget et tar. Il gère les dépendances dans une fonction de 30 lignes, installe les fichiers en une commande tar, et n'est en C++ que pour bénéficier de ce que Qt apporte (QSettings pour la liste des paquets, QHash et QList pour le reste).

      Pour ceux qui s'intéressent au solveur :

      * Annonce du début de la programmation du solveur : http://logram-project.org/news-2-65-1-nouveau-solveur-pour-s(...)
      * Annonce de la disponibilité du nouveau solveur (qui remplace l'ancien à branches qui avait des défauts) : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...)
      * Journal (sur mon site, je les appelle de la même manière parce que j'aime bien) qui parle de mes premiers essais : http://logram-project.org/news-2-64-1-resolution-de-dependan(...)
      * Les hypergraphes, domaine des mathématiques hautement abstrait et complexe, mais au combien puissant : http://fr.wikipedia.org/wiki/Hypergraphe

  • # Limite de documentation ?

    Posté par  . Évalué à 10.

    Salut,

    J'ai du mal à saisir le rapport entre le langage et la documentation. En quoi un outil en shell ne pourrait-il pas être documenté comme il faut ?

    De plus, la gestion des paquets, c'est àmha vraiment un boulot typique pour le shell : le gros œuvre (conditionnement et déploiement des fichiers) est souvent assuré par une commande unique (genre tar/cpio). Le reste c'est juste de la gestion de log et de la mise en place/exécution de fichiers annexes...

    Je proposerais bien spkman/spkcpio, qui produisent et gèrent des paquets Slackware au format CPIO, et sont codés avec dash en essayant de coller au max. à POSIX :

    http://requiescant.tuxfamily.org/spack/index.html

    Mais après avoir jeté un œil à spkg, il est loin d'en avoir toute les fonctionnalités. Pourtant, pour une "distro" (1) comme Saevia, il y aurait sûrement une bonne piste vers la simplicité : qui a besoin de gérer les dépendances, lorsqu'il a compilé tout le système lui-même ? le boulot du gestionnaire sur une telle distro se borne en gros à changer une pièce par une autre, non ?

    Mes 2¢.

    (1) À l'instar de Linux Froms Sratch, ça me paraît plus une méthode qu'une distribution.

  • # Réponse globale

    Posté par  . Évalué à 7.

    Hello,

    Merci à tous pour vos réactions.

    @ Pourquoi ?

    Je ne connaissais ROCK Linux que de nom, je suis allé jeter un coup d'oeil, et cela semble intéressant.
    Néanmoins, j'ai trouvé un guide pour installer ROCK Linux depuis leur framework, mais rien en ce qui concerne la création d'un système sans aucune base, comme le propose LFS ou Saevia.
    Je suppose donc que les objectifs ne sont pas exactement les mêmes. Si je me trompe, dites-le moi.
    Je note aussi que Saevia est un projet francophone, et permet donc aux utilisateurs d'obtenir plus facilement un support...

    @B.

    Effectivement, j'avais premièrement envisagé prendre pacman pour base de travail, mais il contient des dépendances sur pas mal de paquets, comme par exemple openssl, acl, libarchive...
    Ce sont autant de paquets qui sont inutiles pour Saevia.
    Merci néanmoins pour la proposition :)

    @Setup

    En effet, j'étais déjà entré en contact avec toi, Steckdenis, car j'étais très intéressé par les débuts de Setup, mais les dépendances sur QT m'avaient découragées, car ces bibliothèques ne sont pas adaptées à de petits projets.
    Je te contacte néanmoins dans la soirée, merci bien de ton post sympathique, c'est sympathique de ta part...
    Il sera peut-être en effet possible d'apporter des améliorations au setup d'origine pour en faire une version "allégée"

    @dr_home

    Disons qu'un outil shell est presque compréhensible à la lecture, cela ne présente donc pas énormément d'intérêt (dans notre cas uniquement naturellement)

    Merci à tous,
    Nuclear

    • [^] # Re: Réponse globale

      Posté par  . Évalué à 9.

      Disons qu'un outil shell est presque compréhensible à la lecture, cela ne présente donc pas énormément d'intérêt (dans notre cas uniquement naturellement)

      Euh... ouais... sûr que vous faites ce que vous voulez, mais c'est pas un poil tordu de complexifier un outil, juste pour justifier sa documentation ? :|

      Sans compter que comprendre le code du gestionnaire, ça présente quand même peu d'intérêt dans l'appréhension du fonctionnement d'un système Linux. Vous semblez considérer que bâtir un système, c'est le comprendre, et que plus on part de zéro, mieux c'est. De mon (certes petit) point de vue, tout cela est assez secondaire. Bâtir une LFS la truffe sur le bouquin, c'est à la porté de n'importe quel pinpin qui entend étrenner son costume de hacker, mais administrer et maintenir un tel système au quotidien, clairement pas. Bref, si vous manquez de ressources pour votre projet, il y a peut-être de meilleurs aspects dans lesquels investir celles dont vous disposez, non ? :)

    • [^] # Re: Réponse globale

      Posté par  . Évalué à 3.

      Bonsoir,
      le projet a l'air intéressant, Je lirais la doc et testerai plus tard(demain peut être).
      Le fait que le gestionnaire de paquets soit un script shell me semble un avantage. C'est d'ailleurs l'un des éléments qui a attiré mon attention. La deuxième chose qui a attiré mon attention c'est la légèreté de la distrib :-)

      Pourquoi vouloir absolument passer au C pour le gestionnaire de package?

      • [^] # Re: Réponse globale

        Posté par  . Évalué à 2.

        Peut-être pour les performances ? (ceci est une réponse/question sérieuse)

  • # Première impression

    Posté par  . Évalué à 1.

    Bonsoir,
    J'ai lu la documentation et je l'ai trouvé très lisible et complète (je ne suis pas expert, donc c'est que c'est bien écrit :p).

    Je me suis ensuite jeté sur mon PC afin de creer une machine virtuelle(virtualbox) bootant sur le liveCD saevia. ça bootait vite, impressionnant!

    Malheureusement au bout de qq minutes je me suis rendu compte que je n'avais pas de réseau; hehe

    Pas de réseaux avec le liveCD saevia...Pour installer saevia il me faut une autre distribution de Linux...Je trouve ça un peu dommage. Du coups j'ai tout remis à plus tard...

    bonne soirée

Suivre le flux des commentaires

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