Re: [gentoo-user] File collisions while syncing/updateing
On 2019.03.10 22:50, tu...@posteo.de wrote: Hi, I've got this this morning: strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version /usr/lib64/libmxml.so.1.6 * checking 9 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 / ` 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 https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://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. * * Detected file collision(s): * * /usr/share/man/man3/mxml.3.bz2 * /usr/include/mxml.h * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/mxml-2.12:0::gentoo * /usr/include/mxml.h * /usr/lib64/libmxml.so * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/share/man/man3/mxml.3.bz2 * * Package 'dev-libs/mxml-3.0' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. * * The following package has failed to build, install, or execute postinst: * * (dev-libs/mxml-3.0:1/6::gentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/dev-libs/mxml-3.0/temp/build.log' Is it ok tp rm /usr/share/man/man3/mxml.3.bz2 /usr/include/mxml.h /usr/lib64/libmxml.so.1.6 /usr/lib64/pkgconfig/mxml.pc /usr/lib64/libmxml.so.1 /usr/lib64/libmxml.so manually prior to reemergeing? Hello Meino, I'd file a bug, as it looks like 2.12 in slot 0 and 3.0 in slot 1 both install some of the same files. It looks like version 3.0 was just added to the tree, so either it doesn't need to be in a separate slot, or else those files need renaming. Deleting and re-emerging would probably work, but if you later remove one of the versions, those files will also be removed, and the remaining version will probably fail due to the missing .so file(s). Jack
[gentoo-user] File collisions while syncing/updateing
Hi, I've got this this morning: strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version /usr/lib64/libmxml.so.1.6 * checking 9 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 / ` 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 https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://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. * * Detected file collision(s): * * /usr/share/man/man3/mxml.3.bz2 * /usr/include/mxml.h * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/mxml-2.12:0::gentoo * /usr/include/mxml.h * /usr/lib64/libmxml.so * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/share/man/man3/mxml.3.bz2 * * Package 'dev-libs/mxml-3.0' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. * * The following package has failed to build, install, or execute postinst: * * (dev-libs/mxml-3.0:1/6::gentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/dev-libs/mxml-3.0/temp/build.log' Is it ok tp rm /usr/share/man/man3/mxml.3.bz2 /usr/include/mxml.h /usr/lib64/libmxml.so.1.6 /usr/lib64/pkgconfig/mxml.pc /usr/lib64/libmxml.so.1 /usr/lib64/libmxml.so manually prior to reemergeing? Cheers! Meino
[gentoo-user] file collisions
emerge complains that icu (details below) will overwrite files that MAY belong to other packages. But in fact none do. The suggestion is to ignore the collisions. Does that mean I should simply rm the files before retrying the emerge? thanks, allan * Messages for package dev-libs/icu-4.6.1: * Package:dev-libs/icu-4.6.1 * Repository: gentoo * Maintainer: arfre...@gentoo.org * USE:amd64 elibc_glibc kernel_linux multilib userland_GNU * FEATURES: sandbox * Applying icu-4.6.1-parallel_installation.patch ... * 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). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * package dev-libs/icu-4.6.1 NOT merged * * Detected file collision(s): * * /usr/lib64/libicutu.so.46.1 * /usr/lib64/libicuio.so.46.1 * /usr/lib64/libiculx.so.46.1 * /usr/lib64/libicutest.so.46.1 * /usr/lib64/libicudata.so.46.1 * /usr/lib64/libicui18n.so.46.1 * /usr/lib64/libicuuc.so.46.1 * /usr/lib64/libicule.so.46.1 * /usr/lib64/icu/4.6.1/Makefile.inc * /usr/lib64/icu/4.6.1/pkgdata.inc * /usr/share/doc/icu-4.6.1/unicode-license.txt.bz2 * /usr/share/doc/icu-4.6.1/html/readme.html * /usr/share/icu/4.6.1/install-sh * /usr/share/icu/4.6.1/license.html * /usr/share/icu/4.6.1/mkinstalldirs * /usr/share/icu/4.6.1/config/mh-linux * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). * * Package 'dev-libs/icu-4.6.1' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. *
Re: [gentoo-user] file collisions
Allan Gottlieb writes: emerge complains that icu (details below) will overwrite files that MAY belong to other packages. But in fact none do. The suggestion is to ignore the collisions. Does that mean I should simply rm the files before retrying the emerge? Yes. If you think these files might be important, then you could back them up first. Apparently they belong to the icu stuff you are going to remerge anyway, so deleting should be safe I think. But it's strange that those files do not belong to any package. Instead of removing them it would be easier to set FEATURES to -collision- protect. And with FEATURES=keepwork you will not have to recompile icu. So, I would do this: FEATURES=-collision-protect keepwork emerge -1a dev-libs/icu Remember that you have to delete stuff in /var/tmp/portage/dev- libs/icu-4.6.1 manually afterwards. Wonko
Re: [gentoo-user] file collisions
On Thu, May 26 2011, Alex Schuster wrote: Allan Gottlieb writes: emerge complains that icu (details below) will overwrite files that MAY belong to other packages. But in fact none do. The suggestion is to ignore the collisions. Does that mean I should simply rm the files before retrying the emerge? Yes. If you think these files might be important, then you could back them up first. Apparently they belong to the icu stuff you are going to remerge anyway, so deleting should be safe I think. But it's strange that those files do not belong to any package. Instead of removing them it would be easier to set FEATURES to -collision- protect. And with FEATURES=keepwork you will not have to recompile icu. So, I would do this: FEATURES=-collision-protect keepwork emerge -1a dev-libs/icu Remember that you have to delete stuff in /var/tmp/portage/dev- libs/icu-4.6.1 manually afterwards. thank you for the advice, which worked fine. allan
Re: [gentoo-user] file collisions
On Thursday 26 May 2011 17:06:14 Allan Gottlieb wrote: On Thu, May 26 2011, Alex Schuster wrote: Allan Gottlieb writes: emerge complains that icu (details below) will overwrite files that MAY belong to other packages. But in fact none do. The suggestion is to ignore the collisions. Does that mean I should simply rm the files before retrying the emerge? Yes. If you think these files might be important, then you could back them up first. Apparently they belong to the icu stuff you are going to remerge anyway, so deleting should be safe I think. But it's strange that those files do not belong to any package. Instead of removing them it would be easier to set FEATURES to -collision- protect. And with FEATURES=keepwork you will not have to recompile icu. So, I would do this: FEATURES=-collision-protect keepwork emerge -1a dev-libs/icu Remember that you have to delete stuff in /var/tmp/portage/dev- libs/icu-4.6.1 manually afterwards. thank you for the advice, which worked fine. I could swear I saw the same/similar message about collisions, but in my case the package emerged and the files were overwritten. Not sure if I have some FEATURES setting that took care of this. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] file collisions
Mick writes: On Thursday 26 May 2011 17:06:14 Allan Gottlieb wrote: On Thu, May 26 2011, Alex Schuster wrote: FEATURES=-collision-protect keepwork emerge -1a dev-libs/icu Remember that you have to delete stuff in /var/tmp/portage/dev- libs/icu-4.6.1 manually afterwards. thank you for the advice, which worked fine. I could swear I saw the same/similar message about collisions, but in my case the package emerged and the files were overwritten. Not sure if I have some FEATURES setting that took care of this. You probably do not have FEATURES=collision-protect in make.conf, it is not activated by default. The similar FEATURE protect-owned is set by default, but this only refuses to overwrite files belonging to another package. Wonko
