View previous topic :: View next topic |
Author |
Message |
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
Posted: Fri Nov 02, 2012 12:17 am Post subject: [Solved] Boost update - file collisions |
|
|
Yesterday I updated world and there was a new version of dev-libs/boost available. Everything emerged fine:
1351794307: Started emerge on: Nov 01, 2012 19:25:07
1351794307: *** emerge --newuse --deep --update world
1351794326: >>> emerge (1 of 1) dev-libs/boost-1.49.0-r2 to /
1351794326: === (1 of 1) Cleaning (dev-libs/boost-1.49.0-r2::/usr/portage/dev-libs/boost/boost-1.49.0-r2.ebuild)
1351794328: === (1 of 1) Compiling/Merging (dev-libs/boost-1.49.0-r2::/usr/portage/dev-libs/boost/boost-1.49.0-r2.ebuild)
1351794886: === (1 of 1) Merging (dev-libs/boost-1.49.0-r2::/usr/portage/dev-libs/boost/boost-1.49.0-r2.ebuild)
1351794917: >>> AUTOCLEAN: dev-libs/boost:0
1351794917: === Unmerging... (dev-libs/boost-1.49.0-r1)
1351794922: >>> unmerge success: dev-libs/boost-1.49.0-r1
1351794926: === (1 of 1) Post-Build Cleaning (dev-libs/boost-1.49.0-r2::/usr/portage/dev-libs/boost/boost-1.49.0-r2.ebuild)
1351794926: ::: completed emerge (1 of 1) dev-libs/boost-1.49.0-r2 to /
1351794927: === Unmerging... (app-admin/eselect-boost-0.4)
1351794928: >>> unmerge success: app-admin/eselect-boost-0.4
1351794928: *** Finished. Cleaning up...
1351794929: *** exiting successfully.
1351794929: *** terminating.
There was multiple file collisions reported at the end of the emerge: http://dpaste.org/krJZg/
By the looks of it everything seems fine but one question arises, why were the libboost_* files preserved when the old version of boost was unmerged? (thus causing the collisions when the files from the new version installs)
Last edited by DanneStrat on Wed Nov 14, 2012 12:41 pm; edited 1 time in total |
|
Back to top |
|
|
platojones Veteran
Joined: 23 Oct 2002 Posts: 1602 Location: Just over the horizon
|
Posted: Fri Nov 02, 2012 12:23 am Post subject: Re: Boost update - file collisions |
|
|
I ran into that too. I tried un-emerging boost to see if that would clear them, but it didn't. Since equery didn't show they belonged to anything after I un-emerged boost, I just re-emerged it and it worked fine. It's certainly a bug. |
|
Back to top |
|
|
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
Posted: Fri Nov 02, 2012 12:44 am Post subject: |
|
|
platojones,
Thanks for the response. I'll take a closer look at it later and file a bug report if it isn't already reported. I'll keep this thread open for now.
Cheers. |
|
Back to top |
|
|
platojones Veteran
Joined: 23 Oct 2002 Posts: 1602 Location: Just over the horizon
|
Posted: Fri Nov 02, 2012 1:13 am Post subject: |
|
|
Yep...I forgot a step...I had to manually remove the collision files to re-emerge. |
|
Back to top |
|
|
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
Posted: Fri Nov 02, 2012 1:37 am Post subject: |
|
|
platojones wrote: | Yep...I forgot a step...I had to manually remove the collision files to re-emerge. |
Maybe you have "collision-protect" set in make.conf? In my case all the old files were overwritten by the new ones.
collision-protect
A QA-feature to ensure that a package doesn't overwrite
files it doesn't own. The COLLISION_IGNORE variable can
be used to selectively disable this feature. Also see the
related protect-owned feature. |
|
Back to top |
|
|
platojones Veteran
Joined: 23 Oct 2002 Posts: 1602 Location: Just over the horizon
|
Posted: Fri Nov 02, 2012 2:21 am Post subject: |
|
|
Ah, yup, that was it...collision-protect. |
|
Back to top |
|
|
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
|
Back to top |
|
|
chrisstankevitz Guru
Joined: 14 Dec 2003 Posts: 472 Location: Santa Barbara, CA, USA
|
Posted: Sat Nov 03, 2012 10:03 pm Post subject: |
|
|
Hello,
This message is directed toward the people in this thread that seem to know what is going on. I do not know what is going on. I do not know what config_protect is. I do not know what a collisioned file is.
Question: How should I deal with this frightening red-fonted error? (For reference, error pasted below.)
a) revdep-rebuild
b) format hard drive, reinstall gentoo
c) switch to OSX
d) ignore the errors and hope there is no trouble
e) [your idea here]
Thank you,
Chris
Code: | * 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.
*
* Detected file collision(s):
*
* /usr/lib64/libboost_wave-mt.so
* /usr/lib64/libboost_date_time.so
* /usr/lib64/libboost_filesystem-mt.so
* /usr/lib64/libboost_iostreams.so
* /usr/lib64/libboost_serialization.so
* /usr/lib64/libboost_iostreams-mt.so
* /usr/lib64/libboost_wserialization.so
* /usr/lib64/libboost_math_tr1l-mt.so
* /usr/lib64/libboost_math_tr1.so
* /usr/lib64/libboost_locale-mt.so
* /usr/lib64/libboost_wave.so
* /usr/lib64/libboost_random.so
* /usr/lib64/libboost_python-3.2.so
* /usr/lib64/libboost_regex.so
* /usr/lib64/libboost_math_c99l-mt.so
* /usr/lib64/libboost_exception.a
* /usr/lib64/libboost_graph-mt.so
* /usr/lib64/libboost_serialization-mt.so
* /usr/lib64/libboost_thread-mt.so
* /usr/lib64/libboost_test_exec_monitor.a
* /usr/lib64/libboost_regex-mt.so
* /usr/lib64/libboost_date_time-mt.so
* /usr/lib64/libboost_chrono-mt.so
* /usr/lib64/libboost_wserialization-mt.so
* /usr/lib64/libboost_unit_test_framework-mt.so
* /usr/lib64/libboost_math_tr1f-mt.so
* /usr/lib64/libboost_thread.so
* /usr/lib64/libboost_signals-mt.so
* /usr/lib64/libboost_prg_exec_monitor.so
* /usr/lib64/libboost_python-2.7.so
* /usr/lib64/libboost_math_c99.so
* /usr/lib64/libboost_filesystem.so
* /usr/lib64/libboost_prg_exec_monitor-mt.so
* /usr/lib64/libboost_python-3.2-mt.so
* /usr/lib64/libboost_math_tr1f.so
* /usr/lib64/libboost_system-mt.so
* /usr/lib64/libboost_math_c99f-mt.so
* /usr/lib64/libboost_timer-mt.so
* /usr/lib64/libboost_math_c99f.so
* /usr/lib64/libboost_system.so
* /usr/lib64/libboost_unit_test_framework.so
* /usr/lib64/libboost_python-2.7-mt.so
* /usr/lib64/libboost_exception-mt.a
* /usr/lib64/libboost_math_tr1l.so
* /usr/lib64/libboost_math_c99l.so
* /usr/lib64/libboost_random-mt.so
* /usr/lib64/libboost_math_tr1-mt.so
* /usr/lib64/libboost_graph.so
* /usr/lib64/libboost_math_c99-mt.so
* /usr/lib64/libboost_timer.so
* /usr/lib64/libboost_test_exec_monitor-mt.a
* /usr/lib64/libboost_signals.so
* /usr/lib64/libboost_program_options.so
* /usr/lib64/libboost_chrono.so
* /usr/lib64/libboost_program_options-mt.so
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'dev-libs/boost-1.49.0-r2' merged despite file collisions. If
* necessary, refer to your elog messages for the whole content of the
* above message.
|
|
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Sat Nov 03, 2012 10:34 pm Post subject: |
|
|
d)
Logic dictates those could have been only files from the old boost with eselect-boost that were not unmerged, but anyway: no other file claimed the package so your system is perfectly consistent.
EDIT: Well, depending on whether you minor-upgraded from 1.49.0-r1 to -r2 or major-upgraded to 1.51.0-r1 a revdep-rebuild is imminent. |
|
Back to top |
|
|
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
Posted: Sun Nov 04, 2012 1:18 am Post subject: |
|
|
chrisstankevitz,
What genstorm said.
A file collision is when a package installs files that already exist in a directory (unclaimed files or files belonging to another package). One case when this is a bad thing is when two different packages install the same files. In this case with boost, the files from the old boost version aren't cleaned out when the old version is unmerged and when the new version installs, the new files collide with the now unclaimed files from the old version. By default, when portage detects file collisions, the files are overwritten if they don't belong to another package. On the other hand, if you have the option "collision-protect" set in your make.conf (not enabled by default), when portage detects a collision it will not overwrite any files. You would then have to manually remove the listed files to be able to emerge the new version of boost.
You can verify that the files mentioned in the file collision message is now claimed by the new version:
Code: | equery belongs /usr/lib64/libboost_* |
|
|
Back to top |
|
|
chrisstankevitz Guru
Joined: 14 Dec 2003 Posts: 472 Location: Santa Barbara, CA, USA
|
Posted: Sun Nov 04, 2012 6:21 am Post subject: |
|
|
genstorm, dannastrat:
Thank you, I understand. I did not upgrade to boost 1.50 so a revdep-rebuild should not be needed for this.
I suppose the only remaining mystery is "why did portage thing there was a file collision when upgrading boost to 1.49-r2. Perhaps this is a gentoo "bug" and is being discussed in this thread and in the bug tracker.
Thank you again,
Chris |
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5909
|
Posted: Sun Nov 04, 2012 7:11 am Post subject: |
|
|
chrisstankevitz wrote: | Hello,
This message is directed toward the people in this thread that seem to know what is going on. I do not know what is going on. I do not know what config_protect is. I do not know what a collisioned file is.
Question: How should I deal with this frightening red-fonted error? (For reference, error pasted below.)
a) revdep-rebuild
b) format hard drive, reinstall gentoo
c) switch to OSX
d) ignore the errors and hope there is no trouble
e) [your idea here]
Thank you,
Chris
Code: | * 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.
*
* Detected file collision(s):
*
* /usr/lib64/libboost_wave-mt.so
* /usr/lib64/libboost_date_time.so
* /usr/lib64/libboost_filesystem-mt.so
* /usr/lib64/libboost_iostreams.so
* /usr/lib64/libboost_serialization.so
* /usr/lib64/libboost_iostreams-mt.so
* /usr/lib64/libboost_wserialization.so
* /usr/lib64/libboost_math_tr1l-mt.so
* /usr/lib64/libboost_math_tr1.so
* /usr/lib64/libboost_locale-mt.so
* /usr/lib64/libboost_wave.so
* /usr/lib64/libboost_random.so
* /usr/lib64/libboost_python-3.2.so
* /usr/lib64/libboost_regex.so
* /usr/lib64/libboost_math_c99l-mt.so
* /usr/lib64/libboost_exception.a
* /usr/lib64/libboost_graph-mt.so
* /usr/lib64/libboost_serialization-mt.so
* /usr/lib64/libboost_thread-mt.so
* /usr/lib64/libboost_test_exec_monitor.a
* /usr/lib64/libboost_regex-mt.so
* /usr/lib64/libboost_date_time-mt.so
* /usr/lib64/libboost_chrono-mt.so
* /usr/lib64/libboost_wserialization-mt.so
* /usr/lib64/libboost_unit_test_framework-mt.so
* /usr/lib64/libboost_math_tr1f-mt.so
* /usr/lib64/libboost_thread.so
* /usr/lib64/libboost_signals-mt.so
* /usr/lib64/libboost_prg_exec_monitor.so
* /usr/lib64/libboost_python-2.7.so
* /usr/lib64/libboost_math_c99.so
* /usr/lib64/libboost_filesystem.so
* /usr/lib64/libboost_prg_exec_monitor-mt.so
* /usr/lib64/libboost_python-3.2-mt.so
* /usr/lib64/libboost_math_tr1f.so
* /usr/lib64/libboost_system-mt.so
* /usr/lib64/libboost_math_c99f-mt.so
* /usr/lib64/libboost_timer-mt.so
* /usr/lib64/libboost_math_c99f.so
* /usr/lib64/libboost_system.so
* /usr/lib64/libboost_unit_test_framework.so
* /usr/lib64/libboost_python-2.7-mt.so
* /usr/lib64/libboost_exception-mt.a
* /usr/lib64/libboost_math_tr1l.so
* /usr/lib64/libboost_math_c99l.so
* /usr/lib64/libboost_random-mt.so
* /usr/lib64/libboost_math_tr1-mt.so
* /usr/lib64/libboost_graph.so
* /usr/lib64/libboost_math_c99-mt.so
* /usr/lib64/libboost_timer.so
* /usr/lib64/libboost_test_exec_monitor-mt.a
* /usr/lib64/libboost_signals.so
* /usr/lib64/libboost_program_options.so
* /usr/lib64/libboost_chrono.so
* /usr/lib64/libboost_program_options-mt.so
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'dev-libs/boost-1.49.0-r2' merged despite file collisions. If
* necessary, refer to your elog messages for the whole content of the
* above message.
|
|
how does the bold above is an solution? changing os is never the solution (distro maybe a solution if one jumps into deep water without knowing how to swim). _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Sun Nov 04, 2012 9:44 am Post subject: |
|
|
chrisstankevitz wrote: | I suppose the only remaining mystery is "why did portage think there was a file collision when upgrading boost to 1.49-r2. Perhaps this is a gentoo "bug" and is being discussed in this thread and in the bug tracker. |
Most likely explanation, without having ever looked into the eselect-boost mechanism: Those were links that had been previously set by eselect-boost autonomically, which was unmerged in the process. Portage often doesn't remove links for compatibility, e.g. keeping the eselect-boost links in the event of unmerging it to keep boost itself working. In this case, the new boost package then rightfully claimed the links for itself. |
|
Back to top |
|
|
papapenguin l33t
Joined: 20 Sep 2005 Posts: 694 Location: Bellevue
|
Posted: Mon Nov 12, 2012 6:20 pm Post subject: |
|
|
same thing here, but boost merged for me, except for package collisions...
...so I unmerged boost, then ran revdep-rebuild, which brought it back in, but for me, without the collisions... _________________ --------------
Compaq Presario V6120US
AMD Turion 64X2
------------------------ |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Mon Nov 12, 2012 10:34 pm Post subject: |
|
|
Well yes, because removing boost was totally redundant - once the files were overwritten any file collisions were gone. |
|
Back to top |
|
|
DanneStrat n00b
Joined: 05 Jan 2012 Posts: 73
|
Posted: Wed Nov 14, 2012 12:40 pm Post subject: |
|
|
By now, I feel we have a good answer why this collision happens so I'm marking this thread solved. Thanks everyone! |
|
Back to top |
|
|
|