Bug 161103

Summary:	collision-protect symlink handling blinds it to real collisions
Product:	Portage Development	Reporter:	Brian Harring (RETIRED) <ferringb>
Component:	Core	Assignee:	Portage team <dev-portage>
Status:	RESOLVED FIXED
Severity:	normal	Keywords:	InVCS
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	147007

Description Brian Harring (RETIRED) gentoo-dev

2007-01-09 11:33:10 UTC

simple example to demonstrate collision-protects miss (in this case not a horrible miss)-

merge net-libs/liblockfile-1.06-r1
note in the contents no /usr/lib/liblockfile.so.1 entry, and that the file exists on disk (ldconfig creates it)
upgrade to net-libs/liblockfile-1.06-r2
Note it merged that sym, thus stomping a fsentry that it couldn't find an owner to

Now... realize that's not necessarily a bad thing at first glance there; but the check itself (near as I can figure) was written to *only* exclude sym overwrites involving directories.

The problem is, say dev-util/test merges /usr/lib/libcfile.so.0.0.0
dev-util/test-foo merges a symlink of /usr/lib/l -> /usr/lib/foo, and merges /usr/lib/libcfile.so.0.0.0

portage's collision-protect will not pick this up, because the dir exemption doesn't limit itself to _just_ directories- it behaves such that any fs entry that matches the initial path of a symlink is automatically exempted.

Personally, I like my system, but I strongly suspect merging a sym of /u -> /foo would disable all collision detection for /u* matches, which is bad; very least, example given above of where it screw up...

Reproducible: Always

Steps to Reproduce:

Comment 1 Zac Medico gentoo-dev

2007-01-09 18:55:17 UTC

Thanks.  I've applied a minimal fix in svn r5499.

Comment 2 Zac Medico gentoo-dev

2007-01-11 04:16:33 UTC

This has been released in 2.1.2_rc4-r8.