cp behaves differently on FreeBSD. Because of it, dev-python/setuptools-0.6.32 will fail to install. running install_scripts Installing easy_install script to /var/tmp/portage/dev-python/setuptools-0.6.32/image//_python2.7/usr/bin cp: symlink: python-exec: File exists * ERROR: dev-python/setuptools-0.6.32 failed (install phase): * Merging python2.7 image failed. * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 2954: Called distutils-r1_src_install * environment, line 912: Called python_foreach_impl 'distutils-r1_run_phase' 'python_install' * environment, line 2821: Called distutils-r1_run_phase 'python_install' * environment, line 873: Called python_install * environment, line 2845: Called distutils-r1_python_install * environment, line 813: Called die * The specific snippet of code: * cp -a -l -n "${root}"/* "${D}"/ || die "Merging ${EPYTHON} image failed."; Simple Steps to Reproduce 1. cd /tmp 2. mkdir {1,2,3} 3. ln -s python-exec 1/easy_install 4. ln -s python-exec 2/easy_install 5. cp -a -l -v -n 1/* 3/ 6. cp -a -l -v -n 2/* 3/ results on Linux) # cp -a -l -v -n 1/* 3/ '1/easy_install' -> '3/easy_install' # cp -a -l -v -n 2/* 3/ results on FreeBSD) # cp -a -l -v -n 1/* 3/ 1/easy_install -> 3/easy_install # cp -a -l -v -n 2/* 3/ cp: symlink: python-exec: File exists Reproducible: Always
(In reply to comment #0) > cp behaves differently on FreeBSD. > Because of it, dev-python/setuptools-0.6.32 will fail to install. Err, -n (--no-clobber) handles that on Linux. That looks like a bug in FreeBSD to me. @ryao, could you help a bit with this one?
Based on reading the cp source code, I agree that this seems to be a bug. Inside of copy() in cp.c [1], the dne variable is set to 1 based on a call to stat(2). stat(2) attempts to follow symlinks, and returns -1 when called on the easy_install -> python-exec symlink because python-exec doesn't exist in ${D}. !dne is then passed to copy_link in utils.c [2]. copy_link is supposed to remove the destination if it exists (via unlink), but the bad value in dne causes this to be skipped. Since the destination file is not removed, the call to symlink then fails, producing the "cp: symlink: python-exec: File exists" message. I think this could be fixed by changing the stat(2) to lstat(2) in cp.c. copy_link should probably be changed to obey the "-n" flag (nflag) as well. [1] http://svnweb.freebsd.org/base/head/bin/cp/cp.c?view=markup [2] http://svnweb.freebsd.org/base/head/bin/cp/utils.c?view=markup
Thanks for the analysis, Mike. Another thing suggesting that this is a bug is the error message stating the wrong file (link destination).
Created attachment 332902 [details, diff] Patch from upstream Could any of you BSD-ers test the attached patch to cp?
(In reply to comment #4) > Created attachment 332902 [details, diff] [details, diff] > Patch from upstream > > Could any of you BSD-ers test the attached patch to cp? @BSD, could you please test this patch? The OP is not responsive, we don't have any system to test it and the bug is stalled because of lack of it...
Created attachment 335060 [details, diff] sample patch for distutils-r1.eclass (In reply to comment #5) > (In reply to comment #4) > > Created attachment 332902 [details, diff] [details, diff] [details, diff] > > Patch from upstream > > > > Could any of you BSD-ers test the attached patch to cp? > > @BSD, could you please test this patch? The OP is not responsive, we don't > have any system to test it and the bug is stalled because of lack of it... Result of patched cp) # cp -a -l -v -n 1/* 3/ # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. Why copy file will not be displayed ? @bsd, BTW, I don't know the status of Gentoo/*BSD projects other than FreeBSD. Doesn't happen this problem other BSD similarly ? If problem to occur, what about using tar instead of cp.
(In reply to comment #6) > Created attachment 335060 [details, diff] [details, diff] > sample patch for distutils-r1.eclass > > (In reply to comment #5) > > (In reply to comment #4) > > > Created attachment 332902 [details, diff] [details, diff] [details, diff] [details, diff] > > > Patch from upstream > > > > > > Could any of you BSD-ers test the attached patch to cp? > > > > @BSD, could you please test this patch? The OP is not responsive, we don't > > have any system to test it and the bug is stalled because of lack of it... > > Result of patched cp) > > # cp -a -l -v -n 1/* 3/ > # cp -a -l -v -n 1/* 3/ > 3/easy_install not overwritten > > I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. > Why copy file will not be displayed ? You mean that '-v' works incorrectly?
(In reply to comment #7) > (In reply to comment #6) > > Created attachment 335060 [details, diff] [details, diff] [details, diff] > > sample patch for distutils-r1.eclass > > > > (In reply to comment #5) > > > (In reply to comment #4) > > > > Created attachment 332902 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Patch from upstream > > > > > > > > Could any of you BSD-ers test the attached patch to cp? > > > > > > @BSD, could you please test this patch? The OP is not responsive, we don't > > > have any system to test it and the bug is stalled because of lack of it... > > > > Result of patched cp) > > > > # cp -a -l -v -n 1/* 3/ > > # cp -a -l -v -n 1/* 3/ > > 3/easy_install not overwritten > > > > I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. > > Why copy file will not be displayed ? > > You mean that '-v' works incorrectly? Yes. When the option -n is enabled, the following line is seems to be that it does not displayed. 1/easy_install -> 3/easy_install Actual Results # rm 3/* # cp -a -l -v -n 1/* 3/ # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten Expected Results # rm 3/* # cp -a -l -v -n 1/* 3/ 1/easy_install -> 3/easy_install # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten FYI, Option -n is disabled results. # cp -a -l -v 1/* 3/ 1/easy_install -> 3/easy_install
The general issue has been fixed by using tar; I'll leave this bug for the 'cp' bug however.
Created attachment 374808 [details, diff] sample patch for multibuild.eclass dev-python/{pyelftools-0.21-r4,setuptools-2.2} install fails on Gentoo/FreeBSD... * Messages for package dev-python/pyelftools-0.21-r4: * ERROR: dev-python/pyelftools-0.21-r4::gentoo failed (install phase): * python3_3: merging image failed. * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 3546: Called distutils-r1_src_install * environment, line 1211: Called _distutils-r1_run_foreach_impl 'distutils-r1_python_install' * environment, line 233: Called python_parallel_foreach_impl 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 3386: Called multibuild_parallel_foreach_variant '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2529: Called multibuild_foreach_variant '_multibuild_parallel' '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2478: Called _multibuild_run '_multibuild_parallel' '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2476: Called _multibuild_parallel '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2520: Called _python_multibuild_wrapper 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 664: Called distutils-r1_run_phase 'distutils-r1_python_install' * environment, line 1179: Called distutils-r1_python_install * environment, line 1129: Called multibuild_merge_root '/var/tmp/portage/dev-python/pyelftools-0.21-r4/image//_python3.3' '/var/tmp/portage/dev-python/pyelftools-0.21-r4/image/' * environment, line 2509: Called die * The specific snippet of code: * die "${MULTIBUILD_VARIANT:-(unknown)}: merging image failed."; * * If you need support, post the output of `emerge --info '=dev-python/pyelftools-0.21-r4::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-python/pyelftools-0.21-r4::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/environment'. * Working directory: '/var/tmp/portage/dev-python/pyelftools-0.21-r4/work/pyelftools-0.21' * S: '/var/tmp/portage/dev-python/pyelftools-0.21-r4/work/pyelftools-0.21' * * The following package has failed to build or install: * * (dev-python/pyelftools-0.21-r4:0/0::gentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/build.log' *
Created attachment 374810 [details, diff] sample patch for multibuild.eclass (use GNU's cp version) Alternative solution... Add sys-apps/coreutils to DEPEND or @system, use GNU's cp. On FreeBSD, the name of GNU's cp is gcp. # equery f coreutils | grep cp /usr/bin/gcp However, KEYWORDS of coreutils is not enough. (Probably, this problem will also occur on prefix but no KEYWORDS...) http://packages.gentoo.org/package/sys-apps/coreutils?arches=all
We no longer use 'cp -aln' so this bug is obsolete.
Ok, so it's about plain -a as well...
Well, let's make this bug focused purely on weird BSD behavior and not eclasses.
Ok then. Merged just the 'cp -r' -> 'cp -R' change. commit 7adffa3687e1abf7ee24b096b8ab2f39a7ee32b9 Author: Michał Górny <mgorny@gentoo.org> Date: Sat Dec 19 08:57:56 2015 multibuild.eclass: _copy_sources(), use 'cp -R' for BSD compat, #568692 Use 'cp -R' for multibuild_copy_sources() as the '-r' option triggers triggers undesired '-L' behavior wrt symbolic links. Fixes: https://bugs.gentoo.org/show_bug.cgi?id=568692
Sorry, closed the wrong bug.
*-fbsd is gone.
