From the output of an epatch run, it looks like epatch first does a --dry-run on all patches in a given archive before applying them. If the archive contains incremental patches (like "-a +b" and then "-b +c") epatch dies during the --dry-run. Perhaps epatch could iterate over the patches in the archive instead, first testing the patch (--dry-run), then applying, then going to the next patch? Reproducible: Always
please post an actual example. epatch tests each patch by itself before moving on to the next one. if it didnt, many patchesets i personally have made would fall over.
Created attachment 284247 [details] Failure on patchbundle This is the failure reported when applying the patch bundle. The bundle is a compressed archive with all patches in it, ordered by name (starting with a changeset number). I'll put the two patches that are interfering as other attachments.
Created attachment 284249 [details] Patch file 1 First patch (sets a policy from "connectto" to "connectto listen")
Created attachment 284251 [details] Patch file 2 Second patch (sets policy from "connectto listen" to "connectto listen accept")
(In reply to comment #1) > please post an actual example. epatch tests each patch by itself before moving > on to the next one. if it didnt, many patchesets i personally have made would > fall over. Reading the eutils.eclass carefully, lines 377-417, you see that the dry-run is done immediately before the application of each patch. I even wrote a little test case example which I put at http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=tree;f=tests-only/patchorder;h=206404c70df95e2a27f13d600663ab34579ae65a;hb=af7c7816670c7eb933fc8bcc08b5522587797af2 I'll try to figure out what's going on in this case, but I don't think its a problem in epatch.
Sven: please post the actual ebuild too
Created attachment 284325 [details] Ebuild that triggers the epatch This is the ebuild, but you're not going to see much there. I'll also attach the eclass that triggers it (the actual eclass in gentoo-x86 has been updated yesterday to use a different patching method, allowing better debugging and such)
Created attachment 284327 [details] Old(er) selinux-policy-2.eclass Eclass that uses the "epatch patchbundle.tar.bz2" behavior.
Created attachment 284367 [details] Test ebuild This is a test ebuild that triggers the same problem. Doesn't use eclass and uses hardcoded tarballs that I won't touch (specific tarball for this bugreport) so that ongoing development doesn't skew further analysis. The ebuild doesn't match good QA, please excuse me for that :p
i think you're simply mistaken. epatch has never supported operating directly on a tarball of patches. if you unpack the tarball, epatch will work on that unpacked dir, but that's it. from your first log file: PIPE_COMMAND: bzip2 -dc .../distdir/patchbundle-selinux-base-policy-2.20110726-r3.tar.bz2 > .../16763.patch PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '.../16763.patch' notice that there is no `tar` usage there. the tar format basically concats files together into a single file with a little metadata ... and patch is pretty good at skipping that metadata and finding the actual patch. i dont think we need to support patch tarballs directly right now as our current system was worked fine: unpack the tarball, then run `epatch` on the dir.
Sometimes I'm just lucky hitting stuff that isn't supposed to work... ;-) No problem, we're using the epatch (against dir) since a few weeks anyhow.
