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 barmic . É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)
[^] # Re: Wiki
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Oui c'est pertinent, j'attends le mail pour confirmer la création de mon compte et je vais le publier là aussi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Wiki
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Et bien voilà https://wiki.debian.org/fr/DebSrc3/QuickHowto
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# apt-get puis aptitude ?!
Posté par Taurre . É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 :
Pourquoi passer de
apt-get
àaptitude
alors que la commandebuild-dep
est disponible via les deux programmes ?[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (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 kadalka . Évalué à -5.
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 Etienne Bagnoud (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 Marotte ⛧ . É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.
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 Etienne Bagnoud (site web personnel) . Évalué à 3. Dernière modification le 19 juin 2013 à 19:21.
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 Marotte ⛧ . Évalué à 3.
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 Mali (site web personnel) . Évalué à 1.
Non, non pourtant tu n'es pas nouveau ici, kadalka poste à -10
[^] # Re: apt-get puis aptitude ?!
Posté par Marotte ⛧ . Évalué à 2.
Ah déjà ? Il postait à -8 il y a deux jours :)
[^] # Re: apt-get puis aptitude ?!
Posté par Marotte ⛧ . É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 Etienne Bagnoud (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 Marotte ⛧ . É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.
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Oui pour faire les passages d'une version majeure à une autre, apt-get a toujours été recommandé et je l'utilise dans ce cas là.
Non : https://linuxfr.org/nodes/98754/comments/1462980
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Marotte ⛧ . Évalué à 2.
Oui je me suis rendu compte que tu avais déjà répondu sur ce point alors j'ai édité mon message en retirant cette remarque. J'ai du le faire juste pendant que tu écrivais ta réponse ! :)
# debian c'est quand même autre chose
Posté par kadalka . É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 deperl
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 Etienne Bagnoud (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 Marotte ⛧ . É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 julo4lfr . É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 Marotte ⛧ . Évalué à 0.
J'ai un certain coté « donneur de leçons » qui peut être parfois énervant je le reconnais, j'essaie de me soigner :)
[^] # Re: debian c'est quand même autre chose
Posté par anaseto . Évalué à 2.
Dans,
pour le coup le morceau :
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 Marotte ⛧ . Évalué à 0.
Oui :)
C'était redondant du coup j'ai viré les deux /o\
# coquille
Posté par kadalka . Évalué à -9.
redhat-cluser ?
redhat-clusTer !
# C'est gros, mais je ne peux m'en empêcher.
Posté par Sam E. (site web personnel) . Évalué à 2. Dernière modification le 20 juin 2013 à 12:15.
J'ai fait un
apt-get install microsoft-word
sans résultat. Il me manque un dépôt ?—>[exit]
[^] # Re: C'est gros, mais je ne peux m'en empêcher.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Il n'est pas (encore ?) dans les dépôts, mais c'est un petit projet, qui, à mon avis, à certainement beaucoup d'avenir. Tu peux télécharger le logiciel sur le site du projet …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Le même en git et en plus puissant
Posté par benoar . É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) :
On récupère les sources du package (pas besoin d'installer les dépendances, on va compiler à travers pbuilder) :
On se retrouve avec une branche
upstream
qui contient le code original, etmaster
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 :
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 :(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 :
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 :
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 :
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 :
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.