Journal Modification d'un paquet Debian

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
36
19
juin
2013

Sommaire

Il y a fort longtemps, j'ai modifié mon premier paquet Debian. Puis j'ai eu à le refaire. Puis encore une fois. Mais à chaque fois je notais rien de ma démarche. À chaque fois je recommençais presque de zéro. J'ai donc décidé de m'arrêter un instant pour documenter. Certes ça a été documenté et re-documenté des centaines de fois sur le Web, mais je le fais pour moi et si je le publie ici c'est pour m'assurer de ne pas perdre cette documentation (et parce que Facebook ne supporte pas les statuts avec la syntaxe Markdown). Et, finalement, si je le publie rien que pour moi ici, ça pourrait être utile à quelqu'un.

Les outils de base

Pour commencer nous allons installer les outils de base. On retrouve la liste sur le wiki Debian sauf que depuis la sortie de Wheezy, diff doit être remplacé par diffutils. Je rajoute aussi un outil : quilt, un outil de gestion de patch utilisé dans les paquets Debian. Cet outil, dixit Wikipedia, a été créé pour gérer les patchs du noyau Linux et est maintenant intégré à la gestion de paquet Debian.

# aptitude install build-essential devscripts lintian diffutils patch patchutils quilt

Une fois ces paquets installé je configure brièvement quilt pour un usage debianesque en ajoutant dans ~/.quiltrc les lignes suivantes (d'autres méthodes sont proposées sur le wiki) :

  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_NO_DIFF_TIMESTAMPS=1
  QUILT_REFRESH_ARGS="-p ab"

Les sources

Le logiciel que je souhaite modifier porte le doux nom de dlm-pcmk et trouve sa source dans redhat-cluster. Afin d'obtenir tout ça, je me place dans mon répertoire de travail, par exemple ~/src/redhat-cluster. Tout étant prêt, je lance deux sortilèges :

  $ apt-get source redhat-cluster
  # aptitude build-dep redhat-cluster

Le premier me retourne les sources prêtes pour être modifiées (décompressées et tout, si si), le deuxième m'obtient tout ce qui sera nécessaire pour les compiler. Les sources sont dans un répertoire nommé redhat-cluster-3.0.12 ; c'est là que tout va se dérouler ensuite (sous-entendre $ cd redhat-cluster-3.0.12).

Nettoyage

Afin de m'assurer d'avoir un environnement propre pour travailler, je demande aux petits lutins de le faire pour moi en utilisant leur langue et en me faisant passer pour la racine magique.

  $ fakeroot debian/rules clean

Patcher

À ce stade, il est temps de patcher les sources. Comme par hasard (si si), ce paquet source utilise quilt pour la gestion des patches (ce n'est pas forcément le cas mais ça tend à le devenir). Donc nous allons pousser tous les patches en stock sur les sources.

  $ quilt push -a

Et nous allons créer notre nouveau patch.

  $ quilt new fix-dev-write-no-op

Pour faire ce patch, je vais devoir modifier deux fichiers. Il faut donc les indiquer à priori (j'ai essayé de le faire à posteriori mais ça n'a pas fonctionner et je n'ai pas chercher à en savoir plus).

  $ quilt add dlm/include/linux/dlm_plock.h
  $ quilt add group/dlm_controld/plock.c

Je fais mes corrections dans ces deux fichiers et je ferme le tout très simplement (à noter que les commandes quilt doivent être faites à la racine du paquet source).

  $ quilt refresh
  $ quilt pop

Pour que mon changement ait de la gueule, je vais ajouter une entrée à la liste des changements Debian.

  $ dch -i

Mon éditeur texte favori, Microsoft Word, s'ouvre et je décris mon changement.

Compilation

  $ fakeroot debian/rules binary

Et voilà, dans mon répertoire ~/src/redhat-cluster j'ai un ou plusieurs (dans mon cas plusieurs) .deb prêt a être installé sur mon système ou pousser dans mon dépôt Debian.

Conclusion

Le bug corrigé ici a été signalé à Debian, comme rien ne bougeait, j'ai adapté le patch de redhat, j'ai soumis à Debian (avant la sortie de Wheezy), mais le bug est toujours présent … donc je suis condamné à patcher ce paquet encore et encore.
Par ailleurs, si vous devez juste importer un patch avec quilt, après le quilt push il suffit de faire quilt import $FILE.

PS

Si vous voulez nettoyer votre système à la fin (supprimer les build-dep), j'ai trouvé cette jolie ligne sur le web :

  $ sudo aptitude markauto $(apt-cache showsrc redhat-cluster | grep Build-Depends | perl -p -e 's/(?:[\[(].+?[\])]|Build-Depends:|,|\|)//g')

Ça marche du tonnerre (il faut remplacer redhat-cluser par le nom de votre paquet, bien entendu).

  • # Wiki

    Posté par  . Évalué à 7.

    Merci beaucoup pour le partage.

    Je pense que ça irais super bien quelque par par là :
    https://wiki.debian.org/fr/QuickPackageManagement

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

  • # apt-get puis aptitude ?!

    Posté par  . Évalué à 7. Dernière modification le 19 juin 2013 à 17:39.

    Salut,

    Merci pour ce petit mémo.
    Il y a juste une petite question qui me taraude :

    Etienne Bagnoud a écrit : 

    $ apt-get source redhat-cluster
# aptitude build-dep redhat-cluster

    Pourquoi passer de apt-get à aptitude alors que la commande build-dep est disponible via les deux programmes ?

    • [^] # Re: apt-get puis aptitude ?!

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

      Parce que je trouve 'aptitude' plus facile à taper que 'apt-get' donc j'utilise 'apt-get' le moins possible.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: apt-get puis aptitude ?!

        Posté par  . Évalué à -5.

        Parce que je trouve 'aptitude' plus facile à taper que 'apt-get' donc j'utilise 'apt-get' le moins possible.

        Oh non, il ne faut pas se fatiguer avec aptitude… :P

        juste créer un petit alias…
        alias aptget='sudo apt-get'

        Pour supprimer les alias faire:
        unalias aptget

        Un informaticien qui se respecte est une feignasse. Il faut le démontrer pas juste le dire et encore moins le penser.
        Voyons, il faut avoir sa fierté mon bon monsieur… :-)

        • [^] # Re: apt-get puis aptitude ?!

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

          J'évite ce genre de personnalisation parce que quand j'arrive sur un système non personnalisé, je suis agacé.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: apt-get puis aptitude ?!

          Posté par  . Évalué à 1.

          Je pense qu'Etienne connaît la commande alias, tu ne crois pas ?

          Les alias c'est local, personnel, donc quand tu veux indiquer dans un forum ce que tu fais tu ne mets pas des alias (oui OK ça va de soi).

          Mais un autre problème des alias c'est qu'à tout le temps utiliser tes alias au petits oignons tu finis par oublier les commandes réelles et leurs options et tu peux te retrouver comme un con à chercher dans le manuel parce que tu es sur une autre machine qui n'a pas ces alias.

          Néanmoins je comprends ta réaction car l'argument « aptitude est plus facile à taper que apt-get » ça fait sourire :) Surtout sur un clavier AZERTY où le tiret est carrément accessible.

          Un informaticien qui se respecte est une feignasse.

          Même si on a coutume de dire que paresse est mère de génie, dire qu'un informaticien qui se respecte est une feignasse, même sur le ton de la plaisanterie, c'est moyen je trouve.

          Tu aurais simplement commenté : « Pourquoi tu ne fais pas un alias ? » je pense que ce serait mieux passé.

          Mes deux centimes.

          • [^] # Re: apt-get puis aptitude ?!

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 19 juin 2013 à 19:21.

            Surtout sur un clavier AZERTY où le tiret est carrément accessible.

            En Suisse, nous utilisons un clavier QWERTZ où le tiret est accessible au-dessus de [Ctrl], il faut donc plier le petit doigt vers l'intérieure de la paume et c'est l'ongle qui touche la touche finalement. Donc non, pas de apt-get.

            Sinon pour le reste je suis d'accord, sauf que j'ai pas mal pris son commentaire (enfin je sais pas si quelqu'un pense que je l'ai mal pris).

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: apt-get puis aptitude ?!

              Posté par  . Évalué à 3.

              sauf que j'ai pas mal pris son commentaire (enfin je sais pas si quelqu'un pense que je l'ai mal pris).

              Visiblement certains l'ont mal pris (vu la note). Je lui expliquais qu'ici quasiment tout le monde sait ce qu'est un alias et que c'était donc un peu malvenu de nous étaler ses connaissances là dessus. J'essaie de lui apprendre à être pertinent :)

      • [^] # Re: apt-get puis aptitude ?!

        Posté par  . Évalué à 2.

        Oué enfin aptitude et apt-get ce n'est pas le même programme (ils font la même chose mais pas exactement de la même manière, notamment sur la résolution des dépendances (AFAIK)). Effectivement il n'y a pas l'air d'y avoir un équivalent à apt-get source pour aptitude.

        • [^] # Re: apt-get puis aptitude ?!

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

          Oui et aptitude fut, dans Lenny si je me souviens bien, la manière recommandée par le projet pour l'installation des paquets. Comme aptitude est plus facile à taper (pas d'utilisation du petit doigt) j'ai gardé l'habitude et ça m'a jamais posé le moindre problème. Maintenant je sais pas où on en est entre apt-get et aptitude au niveau duquel est recommandé par le projet, mais aptitude me va très bien sauf pour choper les sources, là il n'y a que apt-get.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: apt-get puis aptitude ?!

            Posté par  . Évalué à 3. Dernière modification le 19 juin 2013 à 19:23.

            Il me semble que c'est à nouveau apt-get qui est recommandé. Moi j'ai bien vu la différence lorsque j'ai tenté d'utiliser aptitude (comme d'hab) pour faire la màj Squeeze → Wheezy. Après deux heures de moulinage pour résoudre les dépendances (suite à un premier plantage qui m'indiquait que je devais utiliser une option pour avoir une « profondeur » de résolution des dépendances infinie…) à 100 % de RAM j'ai killé aptitude est j'ai fait ma màj avec apt-get sans problème.

            Je crois qu'un des avantages d'aptitude sur les apt-* c'est qu'il te propose différentes solutions de résolution de dépendance (utile quand on mix les versions par exemple), ce qu'à ma connaissance ne fait pas apt-get.

  • # debian c'est quand même autre chose

    Posté par  . Évalué à -6.

    Bonsoir,

    debian c'est quand même autre chose.
    Chaque fois que je cherche des paquets, quilt est souvent incontournable…

    Comme je l'ai constaté, il arrive parfois que debian pêche un peu dans la documentation.
    Et malgré tout on aime… (Moi, j'aime, les autres je ne sais pas)

    Merci pour cette dépêche si utile.

    Sinon, juste une simple question: pourquoi ne pas utiliser sed au lieu de perl dans la dernière commande de ce journal ?
    (Ce n'est pas une critique c'est une question)

    • [^] # Re: debian c'est quand même autre chose

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

      Parce que ça vient d'un autre (cf le lien) et que lui a décidé d'utiliser perl et que je vais pas réécrire une commande qui fonctionne pour utiliser un autre outil.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: debian c'est quand même autre chose

      Posté par  . Évalué à 5.

      Voilà à quoi aurait du ressembler ton commentaire selon moi :

      Question

      Posté par kadalka le 19/06/13 à 18:53. Évalué à -9.

      Chaque fois que je cherche des paquets, quilt est souvent incontournable…

      Pourquoi ne pas utiliser sed au lieu de perl dans la dernière commande de ce journal ?

      Là c'est tout de suite moins lourd avec exactement la même utilité que ton commentaire original…

      Parce que dire « j'aime Debian » n'est pas utile et dire que « parfois la documentation pèche » ne l'est pas non plus (c'est le lot de quasiment tous les logiciels, libre ou pas d'ailleurs).

      • [^] # Re: debian c'est quand même autre chose

        Posté par  . Évalué à 2.

        Tu te recycles en Maître Cappello du commentaire (il n'est pas nécessaire de reformuler ce commentaire, qu'il reste inutile ne me gêne pas) ?

      • [^] # Re: debian c'est quand même autre chose

        Posté par  . Évalué à 2.

        Dans,

        Pourquoi ne pas utiliser sed au lieu de perl dans la dernière commande de ce journal ?

        pour le coup le morceau :

        (Ce n'est pas une critique c'est une question)

        n'était pas si mal je trouve, sinon ça peut être pris pour le programmeur python attaquant la syntaxe de perl, alors que comme ça, ça exprime juste la perplexité ;)

        • [^] # Re: debian c'est quand même autre chose

          Posté par  . Évalué à 0.

          Oui :)

          Sinon, juste une simple question: pourquoi ne pas utiliser sed au lieu de perl dans la dernière commande de ce journal ?
          (Ce n'est pas une critique c'est une question)

          C'était redondant du coup j'ai viré les deux /o\

  • # coquille

    Posté par  . Évalué à -9.

    redhat-cluser ?

    redhat-clusTer !

  • # C'est gros, mais je ne peux m'en empêcher.

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 20 juin 2013 à 12:15.

    Mon éditeur texte favori, Microsoft Word, s'ouvre et je décris mon changement.

    J'ai fait un apt-get install microsoft-word sans résultat. Il me manque un dépôt ?

    —>[exit]

  • # Le même en git et en plus puissant

    Posté par  . Évalué à 5.

    Intéressant, mais récemment, on [1] est quand même passé à « mieux » avec git et d'autres outils associés. Je me base entre autre sur git-buildpackage [2] et ce guide https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

    On installe l'essentiel (de tête) :

    # apt-get install build-essential devscripts git git-buildpackage cowbuilder

    On récupère les sources du package (pas besoin d'installer les dépendances, on va compiler à travers pbuilder) :

    $ git-import-dsc --download redhat-cluster

    On se retrouve avec une branche upstream qui contient le code original, et master contient les modifications pour Debian.

    On va créer un branche qui contiendra les patchs Debian appliqués, car ils sont normalement stockés dans debian/patches avec quilt, mais ici on utilisera git :

    $ gbp-pq import

    On a donc la branche patch-queue/master sur laquelle travailler. On modifie, on add, on commit, et on en profite pour avoir le changelog qu'on commitera dans la branche master :

    $ git-dch -i -a

    (on peut les mettre dans l'index en attendant). Et on exporte le(s) changement(s) ainsi obtenus en patchs Debian dans la branche principale :

    $ gbp-pq export

    On peut ajouter les patchs ainsi générés et le changelog, commiter, et ça roule.

    On peut ensuite le compiler soi sur son système directement :

    $ git-buildpackage -us -uc

    Voire le faire dans un pbuilder-like, comme ça on n'a pas à polluer son système, et ça permet de vérifier qu'on n'a pas oublié de dépendances, et que ça compile depuis un système propore :

    $ git-pbuilder create
$ git-buildpackage -us -us --git-pbuilder

    Après, ce qui est intéressant, ce sont aussi les bonus :
    - Générer aussi les tar originaux “pristine”, en ajoutant --pristine-tar à git-import-dsc
    - Builder pour différentes suites, en créant une nouvelles branche avec les modifications spécifiques (ou pas), et en passant --git-dist=squeeze à git-buildpackage par exemple (et en précisant --git-debian-branch=ma_branche si on a fait une branche séparée).
    - Pouvoir facilement mettre à jour le patch qu'on a fait quand une nouvelle version du package arrive :

    $ git-import-dsc --download redhat-cluster
$ gbp-pq rebase
    • Les tags automatiques d'après les versions indiquées dans le changelog
    • Etc

    Voilà, j'espère que ça pourra aider.

    [1] Je ne suis ni DM ni DD, juste un packageur du dimanche
    [2] https://sigxcpu.org/piki/projects/git-buildpackage/

Suivre le flux des commentaires

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