Journal sortie de rpmrebuild 2.7

Posté par  (site web personnel) .
Étiquettes :
16
15
juin
2012

Je voudrais vous présenter ce logiciel que je l'ai débuté en juillet 2002. C'est mon premier projet "libre" (au sens de "mis à la disposition de tous sur une forge", sous une licence GPL).

Le logiciel permet de fabriquer un package rpm à partir d'un package installé. L'utilisation de base ne nécessite aucune connaissance du processus de fabrication d'un package, c'est aussi simple que :

rpmrebuild apache

Quel intérêt ? , j'en vois et utilise au moins deux :

  • re-fabriquer un package d'un logiciel installé, dont les sources ont disparues.

  • modifier la configuration d'un logiciel et le re-packager pour l'installer facilement sur d'autres machines

Pour les autres caractéristiques :

  • c'est codé en shell (bash)

  • pour un usage avancé, on peut faire des modifications , soit en interactif, soit via un système de plugins

  • le code gère les traductions (actuellement français/anglais)

  • le logiciel est disponible en contrib dans la pluspart des distributions basées sur rpm : fedora, redhat (epel), mandriva, opensuse, et surement d'autres

Et pour finir, quelques liens :

  • # Bonne idée

    Posté par  . Évalué à 3.

    C'est intéressant, mais il me semble que rpm fournit une option similaire, au moins sur RHEL. Faut que je relise la manpage car je ne sais plus de laquelle il s'agit, mais je crois bien que c'est possible.

    Néanmoins, ça permet de reconstruire un RPM déjà installé, alors que rpmrebuild est peut-être capable de générer un paquet à partir de programmes installés manuellement (dans /usr/local, par exemple).

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Embauche

    Posté par  . Évalué à -9.

    Pour les entretiens d'embauche, je pose souvent cette question.

    1\ Quel est le nombre de ligne du plus gros programme shell que vous ayez codé?

    2\ Est ce que vous en êtes fier?

    if getAnswer(1) > 10 and getAnswer(2) == True:
    print "on vous rappelera..."

    • [^] # Re: Embauche

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

      y dit qu'il voit pas le rapport avec la choucroute…

    • [^] # Re: Embauche

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

      Tu as raté le vendredi de 39 minutes !

    • [^] # Re: Embauche

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

      Je préférerai toujours le mec qui me dit que au dessus de X lignes de shell, il a codé dans un vrai langage de script. (+1 si c'est du perl, +2 si c'est du python).

      • [^] # Re: Embauche

        Posté par  . Évalué à -1.

        et +3 si c'est du ruby

      • [^] # Re: Embauche

        Posté par  . Évalué à 6. Dernière modification le 16 juin 2012 à 23:31.

        le mec qui me dit que au dessus de X lignes de shell, il a codé dans un vrai langage de script

        Pourquoi le shell n´est pas bien ?

        À mon avis, c´est le meilleur langage lorsqu´il s´agit d´automatiser certains traitements systèmes : installer un batch de packages, triturer les fichiers de conf, sauvegarder et restaurer, traiter l´ajout et la suppression d´utilisateurs (vaut mieux automatiser lorsqu´il faut créer les homes, les repositories, affecter les droits… pour des centaines d´utilisateurs qui vont et viennent).

        Comme tout langage, il y a des pièges à éviter. Comme tout langage, il vaut mieux bien architecturer avant de coder. Comme tout langage, il faut coder proprement et respecter des règles.

        De plus, avec bash-4 sont arrivées certaines améliorations qui en font maintenant un langage plutôt intessant : tableaux associatifs (aka dictionnaires), co-process… bash-3 proposait déjà les tableaux indexés, le '$?' pour chaque process d´un pipeline… Mais dans ce cas, il faut utiliser #!/bin/bash, et garder #!/bin/sh pour les scripts réellement POSIX.

        Par exemple, le projet que je maintiens (crosstool-NG) a pour but de compiler l´ensemble des packages nécessaire pour construire une chaîne de cross-compilation : gcc, binutils, librairie C (glibc/eglibc/uClibc/…, installer les en-têtes du noyau, télécharger les archives, les extraire et les patcher, compiler certains packages ou pas en fonction de la config, appliquer des contournements ou pas pour certaines versions, etc… C´est globalement ce qu´il y aurait à taper en ligne de commande si ça de vait être fait à la mimine (./configure --blabla && make blabla && make install, mais en beaucoup plus compliqué et touffu). Résultat : environ 14000 lignes de code shell bash-3 réparties dans environ 70 fichiers. À part en shell, je vois pas en quoi ça aurait pu être codé…

        Bref, dire que quelqu´un est stupide/mauvais/fou/con/… d´avoir utilisé le shell pour écrire un 'gros' programme, c´est comme traiter de la sorte quelqu´un qui fait un gros Makefile pour compiler un gros programme. Si le langage shell est adapté au problème, alors l´utiliser est bien ; s´il n´est pas adapté, alors l´utiliser est mal. C´est comme tout, il faut choisir le meilleur outil pour chaque tâche, et de préférence un outils connu.

        Hop,
        Moi.

        • [^] # Re: Embauche

          Posté par  . Évalué à -1.

          Hehe, le sens de l'humour trollesque, c'est plus ce que c'etait sur linuxfr.. ;o)

          Pour faire ce qui est de crosstool-NG. Je ne le connais pas bien. Je suis un fan d'Open-Embedded depuis le debut, c'est ce projet qui m'a fait decouvrir (et garder) python, quand moi aussi, je m'égarais dans le perl, le bash (et mdk).

          Donc oui, a part en shell, ca aurait pu être code en recettes oe.

          Je repete et je maintiens. Je garde le bash pour les scripts de 10 lignes au plus, ca ne devrais être fait que pour ca!

          Pour le reste, un vrai langage de script moderne, c'est tellement plus productif, et stimulant.

    • [^] # Pourquoi en shell ?

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

      • parce que c'était mon premier projet,

      • qu'il n'y avait pas de traitement de chaînes de caractères,

      • que le code était tout petit au début (en gros des "rpm -q -qf ")

      Au sein du projet, la question a été posée il y a quelques temps. Vu la faible complexité des traitements et l'absence de consensus, nous sommes restés en shell …

      ps : tous mes autres projets ultérieurs sont en perl

    • [^] # Re: Embauche

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

      Ce qui est bien avec une réaction comme ça, c'est qu'on sait qu'on a évité de travailler avec un connard.

    • [^] # Re: Embauche

      Posté par  . Évalué à 8.

      Ça nous évite de trouver une excuse polie pour ne pas vouloir travailler avec toi.

      Tu as aussi une grille de mot que tu coche et si on arrive à tous les dire on a gagné le droit de faire le second entretien ?

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

  • # le screenshot sur sourceforge...

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

    c'est une private joke ?
    http://rpmrebuild.sourceforge.net/screenshots.html

Suivre le flux des commentaires

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