Summary: | epatch should test/patch each patch rather than test all patches first | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sven Vermeulen (RETIRED) <swift> |
Component: | Core - Ebuild Support | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Failure on patchbundle
Patch file 1 Patch file 2 Ebuild that triggers the epatch Old(er) selinux-policy-2.eclass Test ebuild |
Description
Sven Vermeulen (RETIRED)
2011-08-22 18:36:56 UTC
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. |