Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 216470 - portage generated CONTENTS aren't realpath'd
Summary: portage generated CONTENTS aren't realpath'd
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 193766
  Show dependency tree
 
Reported: 2008-04-06 07:41 UTC by Brian Harring (RETIRED)
Modified: 2017-01-08 22:33 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 Brian Harring (RETIRED) gentoo-dev 2008-04-06 07:41:57 UTC
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.
Comment 1 Fabian Groffen gentoo-dev 2010-12-10 17:57:34 UTC
But how can you deal with ${D} containing symlinks or filesystem specific dirs that show up with a realpath?
Comment 2 SpanKY gentoo-dev 2010-12-10 18:20:28 UTC
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.
Comment 3 Sam 2017-01-08 22:26:07 UTC
*ahum* polite bump, maybe close?
Comment 4 Zac Medico gentoo-dev 2017-01-08 22:33:34 UTC
(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.