Summary: | portage generated CONTENTS aren't realpath'd | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Brian Harring (RETIRED) <ferringb> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 193766 |
Description
Brian Harring (RETIRED)
2008-04-06 07:41:57 UTC
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. |