[Solved] Boost update - file collisions

[DanneStrat]

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)

[platojones]

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.

[DanneStrat]

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.

[platojones]

Yep...I forgot a step...I had to manually remove the collision files to re-emerge.

[DanneStrat]

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: Select all

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.

[platojones]

Ah, yup, that was it...collision-protect.

[DanneStrat]

Just had a look in the bugzilla. The issue is reported:
https://bugs.gentoo.org/show_bug.cgi?id=440916

[chrisstankevitz]

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: Select all

 * 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.

[asturm]

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.

[DanneStrat]

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: Select all

equery belongs /usr/lib64/libboost_*

[chrisstankevitz]

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

[DaggyStyle]

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: Select all

 * 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).

[asturm]

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.

[papapenguin]

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...

[asturm]

Well yes, because removing boost was totally redundant - once the files were overwritten any file collisions were gone.

[DanneStrat]

By now, I feel we have a good answer why this collision happens so I'm marking this thread solved. Thanks everyone!