¿Por qué falla el parche GNU para esta diferencia?

Question

G'day,

Editar: solo pensé en mencionar que esta pregunta un tanto larga ahora se soluciona gracias a la respuesta de Adam Goode a continuación si solo estás hojeando mientras pasas.

Me han dado un parche para agregar a Apache 2.2.14 y un diff unificado no está parcheando el archivo en absoluto. Estoy usando el parche GNU 2.5.4.

Tengo que ignorar los espacios en blanco porque el parche original no se hizo bien, es decir, muchas de las diferencias son aparentemente para tab - > Conversiones de espacios. Este tipo de diferencias son aún menos útiles porque el archivo de parche se ha modificado en algún lugar de la cadena de entrega, p. ¡repositorio svn, sistema Jira, interfaz web, etc., para que todas las pestañas se hayan convertido en espacios de todos modos!

El comando que estoy usando en Solaris 10 es:

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

y el resultado es:

...

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.

...

Observe el

Hunk #2 succeeded at 86.

línea.

El archivo de parche contiene varias diferencias unificadas, pero la diferencia relevante es:

...

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

...

y la parte relevante de la fuente, después de aplicar el parche (supuestamente), con algún contexto agregado, es:

...

#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)

...

Todos los demás parches parecen haberse aplicado o ignorado con éxito.

¿Alguna idea de por qué esta diferencia en particular no está tomando?

Editar: Después de reducir el factor de fuzz del parche a cero según lo recomendado por Adam a continuación, el parche ha funcionado con éxito.

¡Gracias a Adam Goode, si pudiera darle otro voto por la respuesta, lo haría! Aquí está el párrafo relevante para fuzz en GNU diffutils manual si está interesado.

Edición 2: Por cierto, hay una advertencia muy relevante en la parte inferior de ese párrafo fuzz:

  El parche

generalmente produce los resultados correctos, incluso cuando debe hacer muchas conjeturas. Sin embargo, los resultados están garantizados solo cuando el parche se aplica a una copia exacta del archivo desde el que se generó el parche.

Desafortunadamente, en este caso, no puedo estar seguro de que su mod_caché.h sea el mismo que el 2.2.14 oficial mod_caché, h! ) -:

Answer 1

Cuando usa --ignore-whitespace y no usa --fuzz = 0 , básicamente le está diciendo al parche que debería hacer un parche de mejor esfuerzo , en lugar de fallar por completo. Debido a que es el mejor esfuerzo, realmente no hay forma de asegurar que funcione perfectamente. Por esta razón, git y Fedora RPM establecen --fuzz = 0 de forma predeterminada para que este tipo de problemas falle en el momento del parche (en lugar de compilar o ejecutar).

Si desea conservar sus archivos como parches + upball-tarball, debe rehacer el parche y asegurarse de que se puede aplicar con --fuzz = 0 .