Hide Forgot
Description of problem: Starting with today's rawhide, the kernel builds have been failing. Looking at the failure lead to something that didn't quite make sense, in that it was saying an file that should exist doesn't. After poking around a bit, I noticed that during the prep for kernel.spec, we're copying the vanilla sources before patching, and that changes a relative symlink in the source into a directory of the contents of the link in the destination. This is most easily seen here: <mock-chroot>[root@vader kernel-3.12.fc21]# ls -l vanilla-3.12/arch/arm/boot/dts/include/ total 0 lrwxrwxrwx. 1 root root 34 Nov 3 18:41 dt-bindings -> ../../../../../include/dt-bindings <mock-chroot>[root@vader kernel-3.12.fc21]# cp -rl vanilla-3.12 vanilla-3.13 <mock-chroot>[root@vader kernel-3.12.fc21]# ls -l vanilla-3.13/arch/arm/boot/dts/include/ total 4 drwxr-xr-x. 11 root root 4096 Dec 18 22:18 dt-bindings <mock-chroot>[root@vader kernel-3.12.fc21]# This then leads to weird patch behavior not creating the file the build expects, but not presenting an error either. Version-Release number of selected component (if applicable): <mock-chroot>[root@vader kernel-3.12.fc21]# rpm -q coreutils coreutils-8.22-1.fc21.x86_64 <mock-chroot>[root@vader kernel-3.12.fc21]# How reproducible: Always thus far. 2 real builds and 1 scratch with coreutils-8.22-1.fc21 and testing in a mock chroot with that all seem to recreate this behavior. Steps to Reproduce: 1. Untar something with a symlink in it 2. cp -rl <source> <dest> 3. Actual results: symlink in <source> is replaced by a copy of the contents in <dest> Expected results: Previous coreutils-8.21 behavior preserved the symlink: [jwboyer@zod kernel-3.12.fc21]$ ls -l vanilla-3.12/arch/arm/boot/dts/include/ total 0 lrwxrwxrwx. 5 jwboyer jwboyer 34 Nov 3 18:41 dt-bindings -> ../../../../../include/dt-bindings [jwboyer@zod kernel-3.12.fc21]$ cp -rl vanilla-3.12 vanilla-3.13 [jwboyer@zod kernel-3.12.fc21]$ ls -l vanilla-3.13/arch/arm/boot/dts/include/ total 0 lrwxrwxrwx. 6 jwboyer jwboyer 34 Nov 3 18:41 dt-bindings -> ../../../../../include/dt-bindings [jwboyer@zod kernel-3.12.fc21]$ rpm -q coreutils coreutils-8.21-18.fc20.x86_64 [jwboyer@zod kernel-3.12.fc21]$ Additional info: I have no idea if this behavior change is expected or not. I also noticed that if I specify 'cp -rdl' it preserves the symlink and that works for both coreutils-8.21 and coreutils-8.22. I opened the bug because I have no clue on the change, and because other packages might hit similar issues. Thoughts?
So this is expected in coreutils-8.22 Gory details here: http://bugs.gnu.org/15173 The summary is that the old behavior was inconsistent. Also `cp -al` is the most common way to create a hard linked tree, and being explicit in its dereferencing behavior, is unimpacted by the change.
BTW this `cp -rl` usage looks quite retricted: https://www.google.com/search?q=site:pkgs.fedoraproject.org+"cp+-rl"
Closing NOTABUG based on Pádraig's explanation.
Adding phracek to cc, as bacula is the second affected component based on padraig's investigation.