Documentation<Précédent | Table des matières | Suivant>
Application d'un patch
Dans l'un de nos cas d'utilisation, nous avons téléchargé le pyrite package source et nous voulons appliquer un correctif que nous avons trouvé dans le référentiel git en amont. C'est une opération courante et elle doit toujours être simple. Malheureusement, les correctifs peuvent être gérés de différentes manières en fonction du format du package source et du workflow de packaging Git utilisé (lorsque Git est utilisé pour maintenir le package).
Avec un paquet source déballé tu as couru apt source pyrite et vous avez un pyrite-0.
répertoire 4.0. Vous pouvez appliquer votre patch directement avec patch -p1 fichier-patch:
$ apt source pyrite
[...]
$ cd pyrite-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ patch -p1
correctif du fichier cpyrit/pckttools.py
$ apt source pyrite
[...]
$ cd pyrite-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ patch -p1
correctif du fichier cpyrit/pckttools.py
Hunk #1 a réussi à 53 (offset -1 lignes).
$ dch --local buxy "Appliquer le correctif pour travailler avec scapy 2.3"
Hunk #1 a réussi à 53 (offset -1 lignes).
$ dch --local buxy "Appliquer le correctif pour travailler avec scapy 2.3"
A ce stade, vous avez patché manuellement le code source et vous pouvez déjà construire des paquets binaires de votre version modifiée (voir la section 9.1.4, « Démarrer le Se construisent” [page 231]). Mais si vous essayez de créer un package source mis à jour, il échouera et se plaindra de « modifications inattendues en amont ». C'est parce que pyrit (comme la majorité des packages source) utilise le format source (voir debian/source/format fichier) connu sous le nom de 3.0 (quilt), où les modifications apportées au code en amont doivent être enregistrées dans des correctifs séparés stockés dans debian/correctifs/ et où le debian/patchs/séries fichier indique l'ordre dans lequel les correctifs doivent être appliqués. Vous pouvez enregistrer vos modifications dans un nouveau patch en exécutant dpkg-source --commit:
$ dpkg-source --commit
dpkg-source : info : modifications locales détectées, les fichiers modifiés sont : pyrit-0.4.0/cpyrit/pckttools.py
Saisissez le nom du patch souhaité : correctif-pour-scapy-2.3.patch
dpkg-source : info : les modifications locales ont été enregistrées dans un nouveau patch : pyrit-0.4.0/debian/
➥ patchs/fix-for-scapy-2.3.patch
$ tail -n 1 debian/patches/séries
correctif-pour-scapy-2.3.patch
$ dpkg-source --commit
dpkg-source : info : modifications locales détectées, les fichiers modifiés sont : pyrit-0.4.0/cpyrit/pckttools.py
Saisissez le nom du patch souhaité : correctif-pour-scapy-2.3.patch
dpkg-source : info : les modifications locales ont été enregistrées dans un nouveau patch : pyrit-0.4.0/debian/
➥ patchs/fix-for-scapy-2.3.patch
$ tail -n 1 debian/patches/séries
correctif-pour-scapy-2.3.patch
Série de patchs de courtepointe Cette convention de gestion des correctifs a été popularisée par un outil nommé courtepointe et le format du package source "3.0 (quilt)" est donc compatible avec cet outil - avec le petit écart qu'il utilise debian/correctifs au lieu de patchs. Cet outil est disponible dans le package du même nom et vous pouvez trouver un joli tutoriel ici :
➨ https://raphaelhertzog.com/2012/08/08/
comment-utiliser-quilt-pour-gérer-les-correctifs-dans-les-paquets-debian/
Série de patchs de courtepointe Cette convention de gestion des correctifs a été popularisée par un outil nommé courtepointe et le format du package source "3.0 (quilt)" est donc compatible avec cet outil - avec le petit écart qu'il utilise debian/correctifs au lieu de patchs. Cet outil est disponible dans le package du même nom et vous pouvez trouver un joli tutoriel ici :
➨ https://raphaelhertzog.com/2012/08/08/
comment-utiliser-quilt-pour-gérer-les-correctifs-dans-les-paquets-debian/
Si le package source utilise le format source 1.0 ou 3.0 (natif), il n'est alors pas nécessaire d'enregistrer vos modifications en amont dans un correctif. Ils sont automatiquement regroupés dans le package source résultant.
Avec un dépôt Git Si vous avez utilisé Git pour récupérer le package source, la situation est encore plus compliquée. Il existe plusieurs workflows Git et outils associés, et évidemment tous les packages Debian n'utilisent pas les mêmes workflows et outils. La distinction déjà expliquée sur le format source est toujours d'actualité mais il faut aussi vérifier si les patchs sont pré-appliqués dans l'arborescence source ou s'ils ne sont stockés que dans debian/correctifs (dans ce cas, ils sont ensuite appliqués au moment de la construction).
L'outil le plus populaire est git-buildpackage. C'est ce que nous utilisons pour gérer tous les dépôts sur git-lab.com/kalilinux/packages. Lorsque vous l'utilisez, les correctifs ne sont pas pré-appliqués dans l'arborescence des sources mais ils sont stockés dans debian/correctifs. Vous pouvez ajouter manuellement des correctifs dans ce répertoire et les répertorier
in debian/patchs/séries mais les utilisateurs de git-buildpackage ont tendance à utiliser GBP pq pour éditer toute la série de patchs en une seule branche que vous pouvez étendre ou rebaser à votre guise. Vérifier gbp-pq(1) pour apprendre à l'invoquer.
git-dpm (avec la commande associée du même nom) est un autre outil d'empaquetage git que vous pouvez trouver en cours d'utilisation. Il enregistre les métadonnées dans debian/.git-dpm et conserve les correctifs appliqués dans l'arborescence des sources en fusionnant une branche constamment rebasée qu'il construit à partir du contenu de debian/correctifs.