web-dev-qa-db-fra.com

Comment gérer les rejets de correctifs après l'application de correctifs avec update?

J'ai utilisé uupdate pour mettre à jour un paquet source de 0.7.0 à 0.7.3. Il fait cette mise à jour avec des correctifs et j'ai eu quelques refus de correctifs. Je ne sais pas quoi faire ensuite. Est ce que je:

  • éditez l'ancien paquet source (0.7.0) puis réexécutez uupdate?
  • éditez le nouveau paquet source (0.7.3) puis relancez uupdate?
  • éditer les fichiers .rej directement?
  • utiliser un outil tel que kdiff3?
  • essayer autre chose?

À ce stade, je pense que la solution consiste à utiliser un outil qui soit plus proche de ce que je connais (issu d’une fusion de la tortue et d’un fond transparent).

J'ai cherché haut et bas la façon dont les gens gèrent les rejets de correctifs et je n'ai pas eu de chance. Je vais donc volontiers RTFM si vous pouvez fournir un lien vers un FM, s'il en existe un .

developmentmotupatch
4
mfisch

Je suis d'accord avec @maco sur la résolution manuelle du conflit. En voyant les options que vous donnez, vous devez probablement vraiment comprendre ce que uupdate does, qui est:

  • extraire la nouvelle archive dans le répertoire parent;
  • essayez d'appliquer le fichier diff.gz précédent (sauf si vous utilisez un style v3 (quilt)) au nouveau répertoire.

Les rejets de correctifs proviennent de l’application de diff.gz au nouveau répertoire.

Maintenant, passez en revue vos options:

  • éditer l'ancien paquet source => vous ne devriez pas modifier l'ancien paquet source pour en créer un nouvea;
  • éditez le nouveau paquet source et relancez uupdate => inutile de le faire, car le correctif ne s’applique pas à la nouvelle source et vous ne devez pas modifier la source originale (sauf avec les correctifs qui se trouvent dans le diff.gz);
  • éditez les fichiers .rej => les fichiers .rej sont là pour vous montrer ce qui n'a pas été appliqué; les modifier ne résoudra pas votre problème, mais vous devriez les jeter un coup d'œil pour voir si les modifications ont échoué. appliqué;
  • utilisez un outil diff => bien sûr, cela peut être une bonne idée, (vim -d est votre ami) bien que les fichiers .rej devraient déjà vous donner une idée de ce qui n'a pas été appliqué. Vous pouvez également lire le fichier précédent diff.gz pour avoir une idée des fichiers qu’il modifiait.

Généralement, la plupart des conflits de mise à jour que j'ai rencontrés étaient dus à un mauvais emballage dans la version précédente du paquet, à savoir un diff.gz qui modifiait la source au lieu d'ajouter simplement un répertoire debian /. Ceci peut être vérifié facilement:

zcat ../yourpackagename_0.7.0-1.diff.gz | diffstat

vous donnera la liste des fichiers modifiés par le patch précédent (adaptez le nom du fichier à vos besoins). Si vous trouvez des fichiers qui ne se trouvent pas dans le répertoire debian/dans cette liste, votre problème est certainement là. Dans ce cas, vérifiez ce qui a été changé:

  • Dans la plupart des cas, il s’agit d’un désordre automatique lorsque debuild -S a été appelé: l’un des scripts autoconf/automake a été modifié et cette modification ne s’applique plus. Il est généralement prudent de supprimer ce changement dans la nouvelle version.
  • Dans d'autres cas, le code source a été corrigé manuellement (sans utiliser dpatch/simple-patchsys/quilt/quoi que ce soit d'autre). Dans ce cas, vérifiez si le correctif doit toujours être appliqué à la nouvelle version (lisez le changelog par exemple). Si tel est le cas, créez un correctif propre à l'aide d'un gestionnaire de correctifs approprié. Les futurs emballeurs vous en remercieront :-)
3
ℝaphink

Je voudrais juste résoudre manuellement les conflits et lancer debuild -S comme d'habitude.

2
maco