Created attachment 559880 [details, diff] no-op-ccache-patch.patch It's a bit confusing to see patch applied successfully. I suggest two things: - for existing EAPIs issue QA warning when patch did nothing - for EAPI=8 issue an error if patch command had no effect. Attaching example on top of ::gentoo's be5c4a9d9cda0adbb1734314bbeadb0ece0eabe6 tree.
Ah, it actually gets applied multiple times. I'll take it upstream.
Executing $ cat P/ccache-3.5.1-configure.patch | patch -p1 -s -g0 --no-backup-if-mismatch applies patch multiple times. $ ccache-3.5.1:git diff | cat diff --git a/configure b/configure index 69325b6..0f581e3 100755 --- a/configure +++ b/configure @@ -643,6 +643,8 @@ more_warnings include_dev_mk getopt_long_c getopt_long_c +getopt_long_c +getopt_long_c extra_libs disable_man host_os @@ -4726,6 +4728,14 @@ fi done +if test x"$ac_cv_func_getopt_long" != x"yes"; then + getopt_long_c="src/getopt_long.c" +fi + +if test x"$ac_cv_func_getopt_long" != x"yes"; then + getopt_long_c="src/getopt_long.c" +fi + if test x"$ac_cv_func_getopt_long" != x"yes"; then getopt_long_c="src/getopt_long.c" fi
Filed upstream bug as: http://savannah.gnu.org/bugs/index.php?55393
(In reply to Sergei Trofimovich from comment #3) > Filed upstream bug as: > http://savannah.gnu.org/bugs/index.php?55393 First comment says: > In automated environments, -F0 is generally a good idea. Maybe we should make that the eapply default for next EAPI. Meanwhile, eapply callers can specify -F0 in the eapply arguments.
Sounds good! Filed bug #674562 for PMS consideration. Bouncing back to dev-portage@ to portage-side changes.
Was rejected by PMS team in https://bugs.gentoo.org/674562#c17. I'll fall back to local hacks to catch such cases. Another one happened in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e744aedf9ec1e2f374acebe42b6d7482e1324618.