Hello all, After stabilizing the new python-exec & eselect-python - Bug 602240 GentooZFS ~ # emerge -pvuDN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-lang/python-exec-2.4.4:2::gentoo [2.0.2:2::gentoo] PYTHON_TARGETS="(jython2_7) (pypy) (pypy3) (python2_7) (python3_4) (python3_5)" 0 KiB [ebuild U ] app-eselect/eselect-python-20160516::gentoo [20140125-r2::gentoo] 0 KiB [blocks b ] <app-eselect/eselect-python-20160206 ("<app-eselect/eselect-python-20160206" is blocking dev-lang/python-exec-2.4.4) Total: 2 packages (2 upgrades), Size of downloads: 0 KiB Conflict: 1 block After emerge -C app-eselect/eselect-python GentooZFS ~ # emerge -pvuDN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-lang/python-exec-2.4.4:2::gentoo [2.0.2:2::gentoo] PYTHON_TARGETS="(jython2_7) (pypy) (pypy3) (python2_7) (python3_4) (python3_5)" 85 KiB [ebuild N ] app-eselect/eselect-python-20160516::gentoo 46 KiB Total: 2 packages (1 upgrade, 1 new), Size of downloads: 131 KiB GentooZFS ~ # emerge =app-eselect/eselect-python-20160516 Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 2) dev-lang/python-exec-2.4.4::gentoo >>> Installing (1 of 2) dev-lang/python-exec-2.4.4::gentoo >>> Failed to install dev-lang/python-exec-2.4.4, Log file: >>> '/var/tmp/portage/dev-lang/python-exec-2.4.4/temp/build.log' >>> Jobs: 0 of 2 complete, 1 failed Load avg: 0.51, 0.48, 0.61 * Package: dev-lang/python-exec-2.4.4 * Repository: gentoo * Maintainer: python@gentoo.org * Upstream: mgorny@gentoo.org https://github.com/mgorny/python-exec/issues/ * USE: abi_x86_64 amd64 elibc_glibc kernel_linux python_targets_jython2_7 python_targets_pypy python_targets_pypy3 python_targets_python2_7 python_targets_python3_4 python_targets_python3_5 userland_GNU * FEATURES: ccache preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking python-exec-2.4.4.tar.bz2 to /var/tmp/portage/dev-lang/python-exec-2.4.4/work >>> Source unpacked in /var/tmp/portage/dev-lang/python-exec-2.4.4/work >>> Preparing source in /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4 ... ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --with-python-impls=jython2.7 pypy pypy3 python2.7 python3.4 python3.5 checking for a BSD-compatible install... /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of x86_64-pc-linux-gnu-gcc... none checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for readlink... yes checking for a sed that does not truncate output... /bin/sed checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4 ... make -j4 make all-am make[1]: Entering directory '/var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4' rm -f python-exec2 python-exec2.tmp /bin/sed -e "s|[@]bindir@|/usr/bin|" \ -e "s|[@]PYTHON_SCRIPTROOT@|/usr/lib/python-exec|" \ -e "s|[@]exeext@||g" src/python-exec.in > python-exec2.tmp x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -DEXEEXT=\"\" -DPYTHON_SCRIPTROOT=\"/usr/lib/python-exec\" -DSYSCONFDIR=\"/etc\" -DNDEBUG -march=native -O2 -pipe -c -o src/python_exec2c-python-exec.o `test -f 'src/python-exec.c' || echo './'`src/python-exec.c chmod a-w,a+x python-exec2.tmp mv python-exec2.tmp python-exec2 x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wl,--hash-style=gnu -o python-exec2c src/python_exec2c-python-exec.o make[1]: Leaving directory '/var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4' >>> Source compiled. >>> Test phase [not enabled]: dev-lang/python-exec-2.4.4 >>> Install python-exec-2.4.4 into /var/tmp/portage/dev-lang/python-exec-2.4.4/image/ category dev-lang make -j4 DESTDIR=/var/tmp/portage/dev-lang/python-exec-2.4.4/image/ install make[1]: Entering directory '/var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4' /bin/mkdir -p '/var/tmp/portage/dev-lang/python-exec-2.4.4/image//usr/bin' /bin/mkdir -p '/var/tmp/portage/dev-lang/python-exec-2.4.4/image//usr/lib/python-exec' /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c python-exec2c '/var/tmp/portage/dev-lang/python-exec-2.4.4/image//usr/bin' /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c python-exec2 '/var/tmp/portage/dev-lang/python-exec-2.4.4/image//usr/lib/python-exec' make[1]: Leaving directory '/var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4' >>> Completed installing python-exec-2.4.4 into /var/tmp/portage/dev-lang/python-exec-2.4.4/image/ * Final size of build directory: 427 KiB * Final size of installed tree: 13 KiB strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version usr/bin/python-exec2c ecompressdir: bzip2 -9 /usr/share/doc * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). See * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to * solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * package dev-lang/python-exec-2.4.4 NOT merged * * Detected file collision(s): * * /usr/bin/python3 * /usr/bin/python-config * /usr/bin/pydoc * /usr/bin/2to3 * /usr/bin/python2 * /usr/bin/python * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). * * Package 'dev-lang/python-exec-2.4.4' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message. * Messages for package dev-lang/python-exec-2.4.4: * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). See * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to * solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * package dev-lang/python-exec-2.4.4 NOT merged * * Detected file collision(s): * * /usr/bin/python3 * /usr/bin/python-config * /usr/bin/pydoc * /usr/bin/2to3 * /usr/bin/python2 * /usr/bin/python * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). * * Package 'dev-lang/python-exec-2.4.4' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message. * GNU info directory index is up-to-date.
The same here. >>> Installing (1 of 2) dev-lang/python-exec-2.4.4::gentoo * checking 15 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). See * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to * solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * package dev-lang/python-exec-2.4.4 NOT merged * * Detected file collision(s): * * /usr/bin/python-config * /usr/bin/python3 * /usr/bin/python * /usr/bin/2to3 * /usr/bin/python2 * /usr/bin/pydoc * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop *
Same here. Those are the packages that python-exec-2.4.4 collide with: ~ # equery b /usr/bin/pydoc * Searching for /usr/bin/pydoc ... dev-lang/python-3.4.5 (/usr/bin/pydoc3.4) ~ # equery b /usr/bin/idle * Searching for /usr/bin/idle ... dev-lang/python-3.4.5 (/usr/bin/idle3.4) ~ # equery b /usr/bin/2to3 * Searching for /usr/bin/2to3 ... dev-lang/python-3.4.5 (/usr/bin/2to3-3.4) ~ # equery b /usr/bin/python-config * Searching for /usr/bin/python-config ... ~ # equery b /usr/bin/python3 * Searching for /usr/bin/python3 ... dev-lang/python-3.4.5 (/usr/bin/python3.4m) ~ # equery b /usr/bin/python2 * Searching for /usr/bin/python2 ... dev-lang/python-2.7.12 (/usr/bin/python2.7) ~ # equery b /usr/bin/python * Searching for /usr/bin/python ... app-eselect/eselect-python-20140125-r2 (/usr/bin/python-wrapper)
Those are unavoidable. We won't be adding any workarounds in ebuilds because that could cause you to end up with no 'python' executable in case or an error. Either use protect-owned, or temporarily disable collision-protect to merge this. I'm going to keep the bug open for some time to reduce duplicates.
*** Bug 605382 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #3) > ... or temporarily disable collision-protect to merge > this. Yeap, I confirm
Thanks
I'm a little confused. Does this mean that these symlinks are no longer going to be provided by dev-lang/python, or is this message going to happen again when a new version of dev-lang/python is stabilised? I'm pretty sure I didn't have any message like this when I installed python-exec-2.0.2 over python-exec-2.0.1-r1 (though it's possible I'm just misremembering). In any case, this seems like a major enough thing that it should probably be a news item in "eselect news".
The symlinks are being replaced to be owned by a single package rather than being unowned. It's a generic effort, though slow-going, aiming to clean up the filesystem from files outside 'writable' directories that are created outside packages. Which means you can expect further collisions in the future as we move more files into packages. You opt in to those errors by using FEATURES=collision-protect. It's a mutual agreement that you want Portage to be extra careful but you agree to investigate every case manually. If you don't want that (and just trust packages always to do the right thing), you can resort to default FEATURES=protect-owned instead.
That's the thing, though. I use FEATURES=protect-owned (as my default setup), but as soon as I saw that the collisions involved Python (and knew that it would be safe to stop it), I Ctrl-C'd it. I wasn't about to risk that without investigation. I've done that now by finding this bug, but even people using the default setup will want to investigate something like this, I reckon. I think that having a news entry for something as major as this is warranted, because collisions are not part of a normal healthy Gentoo maintenance schedule, and many people up to now may not even have seen any. It's a little scary to see it come up.
(In reply to Sophie Hamilton from comment #9) > That's the thing, though. I use FEATURES=protect-owned (as my default > setup), but as soon as I saw that the collisions involved Python (and knew > that it would be safe to stop it), I Ctrl-C'd it. I wasn't about to risk > that without investigation. I've done that now by finding this bug, but even > people using the default setup will want to investigate something like this, > I reckon. > > I think that having a news entry for something as major as this is > warranted, because collisions are not part of a normal healthy Gentoo > maintenance schedule, and many people up to now may not even have seen any. > It's a little scary to see it come up. YES! We definitely need a news entry for such important things.
News item committed now. Let's keep this bug for a while longer so that people who didn't read it can find it.
Thank you! A quick note, though: /usr/bin/idle is also a potential collision. It was on my system.
