Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Solved] Boost update - file collisions
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Fri Nov 02, 2012 12:17 am    Post subject: [Solved] Boost update - file collisions Reply with quote

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
View user's profile Send private message
platojones
Veteran
Veteran


Joined: 23 Oct 2002
Posts: 1555
Location: Just over the horizon

PostPosted: Fri Nov 02, 2012 12:23 am    Post subject: Re: Boost update - file collisions Reply with quote

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
View user's profile Send private message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Fri Nov 02, 2012 12:44 am    Post subject: Reply with quote

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
View user's profile Send private message
platojones
Veteran
Veteran


Joined: 23 Oct 2002
Posts: 1555
Location: Just over the horizon

PostPosted: Fri Nov 02, 2012 1:13 am    Post subject: Reply with quote

Yep...I forgot a step...I had to manually remove the collision files to re-emerge.
Back to top
View user's profile Send private message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Fri Nov 02, 2012 1:37 am    Post subject: Reply with quote

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.
Code:
man make.conf

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
View user's profile Send private message
platojones
Veteran
Veteran


Joined: 23 Oct 2002
Posts: 1555
Location: Just over the horizon

PostPosted: Fri Nov 02, 2012 2:21 am    Post subject: Reply with quote

Ah, yup, that was it...collision-protect.
Back to top
View user's profile Send private message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Fri Nov 02, 2012 1:41 pm    Post subject: Reply with quote

Just had a look in the bugzilla. The issue is reported:
https://bugs.gentoo.org/show_bug.cgi?id=440916
Back to top
View user's profile Send private message
chrisstankevitz
Guru
Guru


Joined: 14 Dec 2003
Posts: 472
Location: Santa Barbara, CA, USA

PostPosted: Sat Nov 03, 2012 10:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2482
Location: Austria

PostPosted: Sat Nov 03, 2012 10:34 pm    Post subject: Reply with quote

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.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Sun Nov 04, 2012 1:18 am    Post subject: Reply with quote

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
View user's profile Send private message
chrisstankevitz
Guru
Guru


Joined: 14 Dec 2003
Posts: 472
Location: Santa Barbara, CA, USA

PostPosted: Sun Nov 04, 2012 6:21 am    Post subject: Reply with quote

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
View user's profile Send private message
DaggyStyle
Advocate
Advocate


Joined: 22 Mar 2006
Posts: 4971

PostPosted: Sun Nov 04, 2012 7:11 am    Post subject: Reply with quote

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
ProjectFootball
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2482
Location: Austria

PostPosted: Sun Nov 04, 2012 9:44 am    Post subject: Reply with quote

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.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
papapenguin
l33t
l33t


Joined: 20 Sep 2005
Posts: 694
Location: Bellevue

PostPosted: Mon Nov 12, 2012 6:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2482
Location: Austria

PostPosted: Mon Nov 12, 2012 10:34 pm    Post subject: Reply with quote

Well yes, because removing boost was totally redundant - once the files were overwritten any file collisions were gone. ;)
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
DanneStrat
n00b
n00b


Joined: 05 Jan 2012
Posts: 70

PostPosted: Wed Nov 14, 2012 12:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum