Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 400783 - sys-apps/portage-2.1.10.41: collisions may result from symlinks created via _post_src_install_soname_symlinks
Summary: sys-apps/portage-2.1.10.41: collisions may result from symlinks created via _...
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-25 18:31 UTC by Ian Stakenvicius (RETIRED)
Modified: 2012-01-25 21:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Stakenvicius (RETIRED) gentoo-dev 2012-01-25 18:31:57 UTC
sys-libs/talloc-2.0.1-r1 did not create the soname symlink 'libtalloc.so.2', and so a QA notice was fired and and that file was created by portage duing the qmerge process, via the function '_post_src_install_soname_symlinks()' located in /usr/$(libdir)/portage/pym/portage/package/ebuild/dobuild.py

sys-libs/talloc-2.0.1-r2 fixes the QA issue by creating the symlink during src_install, but at qmerge time the package reports a collision with the already-installed file /usr/$(libdir)/libtalloc.so.2 (the one auto-created when emerging -r1).

Running equery b libtalloc.so.2 _does_ report it as being owned by talloc-2.0.1-r1, but for some reason this collision is still reported.  I do not know the operational details of the collision check (nor would I understand them without significant study) but it would seem to me that the '_post_src_install_soname_symlinks()' function does not register the files it creates in a way that is compatible with the collisions check.

This was tested on a stable x86 and a stable amd64 system; the issue seems to be independent of profile or arch.

Steps to reproduce:
emerge -1 =sys-libs/talloc-2.0.1-r1 && \
emerge -1 =sys-libs/talloc-2.0.1-r2
Comment 1 Zac Medico gentoo-dev 2012-01-25 19:20:54 UTC
(In reply to comment #0)
> Running equery b libtalloc.so.2 _does_ report it as being owned by
> talloc-2.0.1-r1, but for some reason this collision is still reported.

Maybe equery de-references symlinks, while portage does not. You can use portageq to see if portage thinks it belongs:

  portageq owners / /usr/lib/libtalloc.so.2

> I do
> not know the operational details of the collision check (nor would I understand
> them without significant study) but it would seem to me that the
> '_post_src_install_soname_symlinks()' function does not register the files it
> creates in a way that is compatible with the collisions check.

Since portage-2.1.10.41, a warning is issued, but no symlink is created (see bug 387053). So, I think that there really is a collision, and that equery b is misleading because it's de-referencing the symlink.

Note that the collision should not cause emerge to bail out unless FEATURES=collision-protect is enabled, which is not the default behavior. By default, FEATURES=protect-owned is enabled, and it will only warn about this case.
Comment 2 Ian Stakenvicius (RETIRED) gentoo-dev 2012-01-25 21:08:22 UTC
..  I cannot reproduce the case where libtalloc.so.2 is reported as owned by anything with 'equery b'.  I guess the real issue is that this QA check on older portage's did not register the file it created as part of the package, but there isn't anything that can be done about it now (from the portage point of view, at least) so the point is moot.

Closing bug as RESO/INVA