Pourquoi le correctif GNU échoue-t-il pour ce diff?

Question

G'day,

Modifier: je pensais mentionner que cette question un peu longue est maintenant résolue grâce à la réponse d'Adam Goode ci-dessous si vous ne faites que survoler en passant.

On m'a donné un correctif à ajouter à Apache 2.2.14 et un diff unifié ne corrige pas le fichier. J'utilise le correctif GNU 2.5.4.

Je dois ignorer les espaces, car le correctif original n’a pas été correctement créé. En d'autres termes, de nombreux diffs sont apparemment pour Tab - > conversions d'espaces. Ces types de différences sont encore moins utiles car le fichier de correctif a été modifié quelque part dans la chaîne de diffusion, par exemple. svn repository, le système Jira, l'interface Web, etc., afin que tous les onglets aient été convertis en espaces!

La commande que j'utilise sous Solaris 10 est la suivante:

/usr/bin/gpatch --verbose --ignore-whitespace -p1 -d . \
    <mod_cache.diff

et le résultat est:

...

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: httpd/modules/cache/mod_cache.h
|===================================================================
|--- httpd/modules/cache/mod_cache.h
|+++ httpd/modules/cache/mod_cache.h
--------------------------
Patching file modules/cache/mod_cache.h using Plan A...
Hunk #1 succeeded at 24.
Hunk #2 succeeded at 86.
Hunk #3 succeeded at 138.
Hunk #4 succeeded at 163.
Hunk #5 succeeded at 184.
Hunk #6 succeeded at 217.
Hunk #7 succeeded at 271.
Hunk #8 succeeded at 380.

...

Notez le

Hunk #2 succeeded at 86.

ligne.

Le fichier de correctif contient plusieurs diffs unifiés, mais le diff pertinent est:

...

Index: httpd/modules/cache/mod_cache.h
===================================================================
--- httpd/modules/cache/mod_cache.h
+++ httpd/modules/cache/mod_cache.h
@@ -86,9 +86,13 @@
 #define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
 #define DEFAULT_CACHE_EXPIRE    MSEC_ONE_HR
 #define DEFAULT_CACHE_LMFACTOR  (0.1)
+#define DEFAULT_CACHE_MAXAGE    5
+#define DEFAULT_CACHE_LOCKPATH "/mod_cache-lock"
+#define CACHE_LOCKNAME_KEY "mod_cache-lockname"
+#define CACHE_LOCKFILE_KEY "mod_cache-lockfile"

-/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and
- * PROXY_DECLARE_DATA with appropriate export and import tags for the platform
+/* Create a set of CACHE_DECLARE(type), CACHE_DECLARE_NONSTD(type) and
+ * CACHE_DECLARE_DATA with appropriate export and import tags for the platform
  */
 #if !defined(WIN32)
 #define CACHE_DECLARE(type)            type

...

et la partie pertinente de la source, après l'application du correctif (soi-disant), avec un contexte ajouté, est:

...

#define MSEC_ONE_DAY    ((apr_time_t)(86400*APR_USEC_PER_SEC)) /* one day, in microseconds */
#define MSEC_ONE_HR     ((apr_time_t)(3600*APR_USEC_PER_SEC))  /* one hour, in microseconds */
#define MSEC_ONE_MIN    ((apr_time_t)(60*APR_USEC_PER_SEC))    /* one minute, in microseconds */
#define MSEC_ONE_SEC    ((apr_time_t)(APR_USEC_PER_SEC))       /* one second, in microseconds */
#define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
#define DEFAULT_CACHE_EXPIRE    MSEC_ONE_HR
#define DEFAULT_CACHE_LMFACTOR  (0.1)

/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and 
 * PROXY_DECLARE_DATA with appropriate export and import tags for the platform
 */
#if !defined(WIN32)
#define CACHE_DECLARE(type)            type
#define CACHE_DECLARE_NONSTD(type)     type
#define CACHE_DECLARE_DATA
#elif defined(CACHE_DECLARE_STATIC)

...

Tous les autres correctifs semblent avoir été appliqués avec succès ou ignorés.

Avez-vous des idées sur la raison pour laquelle ce diff particulier ne prend pas?

Modifier: Après la réduction à zéro du facteur fuzz du correctif, comme recommandé par Adam ci-dessous, le correctif a fonctionné correctement.

Merci à Adam Goode, si je pouvais vous donner un autre vote, votez pour la réponse! Voici le paragraphe pertinent pour le fuzz dans les versions de GNU manuel si vous êtes intéressé.

Modifier 2: BTW Il y a cette mise en garde très pertinente au bas de ce paragraphe fuzz:

  Le correctif

produit généralement les résultats corrects, même s'il doit faire de nombreuses suppositions. Cependant, les résultats ne sont garantis que lorsque le correctif est appliqué à une copie exacte du fichier à partir duquel le correctif a été généré.

Malheureusement, dans ce cas, je ne peux pas être sûr que leur mod_cache.h est identique à la version officielle 2.2.14 mod_cache, h! ) -:

Answer 1

Lorsque vous utilisez - ignore-whitespace et que vous n'utilisez pas - fuzz = 0 , vous indiquez à patch qu'il convient de faire un correctif au mieux. , au lieu d’échouer complètement. Parce que c'est le meilleur effort, il n'y a vraiment aucun moyen de s'assurer que cela fonctionnera parfaitement. Pour cette raison, git et Fedora RPM définissent - fuzz = 0 par défaut, de sorte que ces types de problèmes échouent au moment du patch (au lieu de la compilation ou de l'exécution).

Si vous souhaitez conserver vos fichiers en tant que correctifs dans upstream-tarball, vous devez rétablir le correctif et vous assurer qu'il peut s'appliquer avec - fuzz = 0 .