Perché la patch GNU non riesce per questa differenza?

Question

Buongiorno,

Modifica: ho pensato di menzionare che questa domanda piuttosto lunga è ora risolta grazie alla risposta di Adam Goode di seguito se stai solo sfiorando mentre passi.

Mi è stata data una patch da aggiungere ad Apache 2.2.14 e un diff unificato non sta affatto riparando il file. Sto usando la patch GNU 2.5.4.

Devo ignorare gli spazi bianchi perché la patch originale non è stata resa bene, vale a dire che molte differenze sono apparentemente per tab - > conversioni di spazi. Questi tipi di diff sono ancora meno utili perché il file patch è stato modificato da qualche parte lungo la catena di consegna, ad es. repository svn, sistema Jira, interfaccia web, ecc., in modo che tutte le schede siano state convertite comunque in spazi!

Il comando che sto usando su Solaris 10 è:

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

e l'output è:

...

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.

...

Nota

Hunk #2 succeeded at 86.

Linea.

Il file patch contiene diverse differenze unificate ma la differenza rilevante è:

...

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

...

e la parte pertinente della fonte, dopo aver applicato la patch (presumibilmente), con un po 'di contesto aggiunto, è:

...

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

...

Sembra che tutte le altre patch siano state applicate o ignorate con successo.

Qualche idea sul perché questa particolare differenza non stia prendendo?

Modifica: Dopo aver ridotto il fattore fuzz di patch a zero come raccomandato da Adam di seguito, la patch ha funzionato correttamente.

Grazie ad Adam Goode, se potessi darti un altro voto per la risposta, lo farei! Ecco il paragrafo pertinente per fuzz nel diffutils GNU manuale se sei interessato.

Modifica 2: BTW C'è questo avvertimento molto rilevante nella parte inferiore di quel paragrafo fuzz:

  La patch

di solito produce i risultati corretti, anche quando deve fare molte ipotesi. Tuttavia, i risultati sono garantiti solo quando la patch viene applicata a una copia esatta del file da cui è stata generata la patch.

Sfortunatamente, in questo caso, non posso essere sicuro che il loro mod_cache.h sia uguale al mod_cache ufficiale 2.2.14, h! ) -:

Answer 1

Quando usi --ignore-whitespace e non usi --fuzz = 0 , stai fondamentalmente dicendo a patch che dovrebbe fare una patch con il massimo sforzo , invece di fallire completamente. Perché è il miglior sforzo, non c'è davvero alcun modo per assicurare che funzionerà perfettamente. Per questo motivo, git e Fedora RPM impostano --fuzz = 0 di default in modo che questi tipi di problemi falliscano al momento della patch (invece che in fase di compilazione o runtime).

Se vuoi conservare i tuoi file come patch upstream-tarball +, dovresti rifare la patch e assicurarti che possa applicarsi con --fuzz = 0 .