Portage relies on the layout of the pkg contents in ${D} to generate the vdb merged contents. Problem here is that the realpath w/in ${D} isn't necessarily the same as ${ROOT}. Simple example, try python-2.4.4-r6 on amd64; it installs to ${D}/usr/lib/*, portage records it as /usr/lib/* when in reality the realpath is ${D}/usr/lib64/*. Via this, it's implicitly creating a dependency on any symlinks encountered in path resolution- change to that link, or replacement of that sym w/ a dir (something portage will do under the right circumstances), the manager no longer has valid paths for unmerging, thus the files are lost. This also means that doing file lookups contents wise is far more tricky- have to do several realpaths to determine the potential locations the CONTENTS recorded. Actually makes that performance pretty crappy- to do it perfectly, would have to realpath every contents entry looked at.
But how can you deal with ${D} containing symlinks or filesystem specific dirs that show up with a realpath?
i think the current CONTENTS behavior is correct. if i install into $D/usr/lib/ then i expect that to be what CONTENTS states. if someone does something weird & transitory like /sbin -> /mnt/space/backup/sbin, then your solution would randomly break packages when they move /mnt/space/backup/sbin back to /sbin.
*ahum* polite bump, maybe close?
(In reply to SpanKY from comment #2) > i think the current CONTENTS behavior is correct. if i install into > $D/usr/lib/ then i expect that to be what CONTENTS states. Agreed. Writing the realpath in CONTENTS would be lossy. Also consider that it's nice that quickpkg results are not affected by random symlinks on the local system.