| Summary: | ecompressdir does not fix broken links across directories in some cases | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Renato Alves <simpledark> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | dtardon |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 172589 | ||
|
Description
Renato Alves
2007-04-08 21:41:29 UTC
hmm, interesting test case ... man1/foo.1 -> ../man8/man.8 the compression happens: man1/ man5/ man8/ when the man1/ subdir is compressed, the link is not broken yet so it doesnt get fixed ... This is fixed in svn r6361:6363. hmm, this changed from compressing each mandir individually to compressing the parent dir ... i had changed this behavior on purpose as i also changed the man compression to be smarter ... old portage would only compress a few known locations and skip non standard ones (like gcc or binutils or stuff in /opt) ... i changed it so that it would search $D for directories named "man" and then only compress things in there if it closely resembled a man dir structure (aka man/man[some suffix]/) just in case there was a directory out there named "man" that did not actually contain man pages of course, i'm not aware of any such case, so if my erring on the side of caution is not needed, i think we can stick with the proposed change ... (In reply to comment #3) > old portage would only compress a few known locations and skip non standard > ones (like gcc or binutils or stuff in /opt) ... i changed it so that it would > search $D for directories named "man" and then only compress things in there if > it closely resembled a man dir structure (aka man/man[some suffix]/) just in > case there was a directory out there named "man" that did not actually contain > man pages In svn r6370:6372 I've added back the old heuristics to make sure that we don't just blindly compress the contents of any directory named "man". hmm actually i think you may be on to something ... what if we invoke ecompressdir with all of the directories at once and we delay the broken symlink processing until after all directories have been compressed, that should address this issue actually looks like Zac's latest changes addresses all issues here ... cheers This has been released in 2.1.2.4. *** Bug 176283 has been marked as a duplicate of this bug. *** |
