- I understand from kernel-2.eclass code that the unipatch() procedure determines the PATCH_LEVEL using some sort of trial and error algorithm consisting in using the lowest level for which the patch --dry-run command does not return an error. - This might have worked well until now, but, per pure chance only as there is at least one corner case for which it silently fails, leading to an apparently successful emerge but potentially unbuildable kernel. - This is when it happens that the patch file contains only diffs referencing the old filename as /dev/null, that is to say whenever new files are to be created. - If we consider that pathnames for kernel patches are generally coded using the following scheme : Some_Author_Dependent_Dir/Some_Kernel_Path/Some_Filename then, of course, such patches are meant to be applied -p1 - Starting the unipatch() while loop with PATCH_LEVEL=0 - If the patch file contains at least one diff for which the old filename is not /dev/null, then the patch command will take the old filename as reference, but it wont find any Some_Author_Dependent_Dir in the local tree and the --dry-run will return an error leading to the increment of PATCH_LEVEL and another try with PATCH_LEVEL=1 which will be successful. - However, if all diffs' old filenames refer to /dev/null, then the patch command does not look for any existing file to patch as it will create a new file under the name of the new filename. So the unipatch() --dry-runs exits with no error. - So PATCH_LEVEL = 0 will appear as a valid value and the patch be actually applied -p0, this resulting in the creation of a Some_Author_Dependent_Dir/Some_Kernel_Path/Some_Filename file instead of the creation of the Some_Kernel_Path/Some_Filename file as originally intended. Reproducible: Always
In the description above, please read PATCH_DEPTH instead of PATCH_LEVEL. Apologizes.
Any reproducible steps so I can see it live?
Created attachment 325324 [details] TEST-CASE-ONLY : ebuild example to reproduce the problem Ebuild for reproducing the problem which will occur with the ${XPR_2_FILE} patch. Please set the "experimental" and "urwlocks" use flags.
Created attachment 325328 [details] TEST-CASE : Example of patch inappropriatly patched p0 TEST-CASE-ONLY : Example of file the algo will incorrectly patch -p0 Used as ${XPR_2_FILE} in the ebuild attached.
(In reply to comment #2) > Any reproducible steps so I can see it live? And, by the way, if you want to actually *see* something, then you are likely to add some code within the unipatch() procedure that will incidentally satisfy the enhancement request I made as part of Bug 436402, so... please... do not clean all your traces after having seen... ;-)
OK, having read the eclass more... carefully, I realize that the initial value for PATCH_DEPTH can be specified as part of the UNIPATCH_LIST string. I apologize for the noise.
