Proper relative paths in user patches?

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

Wow...I hope someone can clarify this one for me. I'm completely confused as to the proper relative paths that should appear when creating a patch for epatch_user, and it's something that's screwed me up royally on many occasions. I just jumped through hoops with this with the nvidia-drivers for my legacy nvidia card. I'd forgotten that I had nvidia-drivers-304.131-r4 patched for newer kernels (to prevent unknown symbol errors for mtrr_del and mtrr_add), so the upgrade to x11-drivers/nvidia-drivers-304.134 caused a module that wouldn't load.

The patch I had in the former had this:

eccerr0r · Posted: Sat Dec 31, 2016 7:35 pm Post subject:

Yeah the EAPI change makes different assumptions, I recall seeing this in another patch problem. Portage will remove levels of directories from your patch file paths, but EAPI6 will remove one more level it seems.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

asturm · Developer Joined: 05 Apr 2007 Posts: 9014

Basically, with git-format you are fine. (has worked pre-EAPI-6, and is the only way now).

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

asturm · Developer Joined: 05 Apr 2007 Posts: 9014

I said git-format because it gives you exactly the -p1 paths that you need.

mythweb is just a very bad example. It's doing `cd "${S}"/../` within src_prepare and then calling eapply_user. That's why it appears to you as if it needs another directory level above. Similarly, nvidia-drivers has S=${WORKDIR}.

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

Wow...wow...wow. I'm resurrecting this old post because this one continues to be the biggest mystery to me when it comes to gentoo. I just do NOT get the rules as far as a proper relative path to use in user patches for ebuilds. It seems I never get it correct. My understanding was that in general, the path you'd get with git diff would be correct. Here's another example where this wasn't correct...with the EAPI 6 mythtv-29.1-r1.ebuild here:

https://packages.gentoo.org/packages/media-tv/mythtv

Maybe in this case it's doing something screwy I'm not seeing. In any case, if I actually check that same version out from the mythtv git, a code change followed by a git diff ends up with paths like this:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22148

Patches applied by eapply are done in src_prepare. They must be relative, after stripping, to the current working directory when eapply is called. In the default src_prepare, this is $S. $S is usually, but not necessarily, "${WORKDIR}/${P}", the top level directory containing unpacked source files from upstream. The MythTV ebuild overrides $S, so its src_prepare runs from an unusual directory, which gives you unusual rules.

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

OK. Than makes sense. The $S assignment was what I was missing. I assume all the same is true for the apply_user that's being called implicitly in src_prepare (as of EAPI 6). I just happen to have run into a lot of oddball examples.

Thanks!
Tom

Hu · Administrator Joined: 06 Mar 2007 Posts: 22148

Correct, eapply_user is bound by the same rules. One other quirk that may have worked against you is that the older epatch family would probe a range of -p values, so you could get away with putting too many levels of path context in your patch. The newer eapply family always guesses -p1, so you must use the proper depth now. I think the feature of guessing various -p levels was abandoned because it could theoretically do the wrong thing in certain odd scenarios.

tld · Veteran Joined: 09 Dec 2003 Posts: 1829

Thanks! Yea, I was aware of that change to force -p1. I'm sure you're correct and I assumed the same. That is that in theory, attempting various -p levels could attempt to patch an incorrect file by the same name in another directory. Makes total sense.

Tom