Bug 173808 – ecompressdir does not fix broken links across directories in some cases

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Renato Alves 2007-04-08 21:41:29 UTC]

renice.1 manpage at man1 symlinks to ../man8/renice.8 instead of ../man8/renice.8.bz2

getty.1 manpage at man1 symlinks to ../man8/agetty.8 instead of ../man8/agetty.8.bz2

Reproducible: Always

[Comment 1 SpanKY 2007-04-08 23:19:24 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 ...

[Comment 2 Zac Medico 2007-04-10 08:42:20 UTC]

This is fixed in svn r6361:6363.

[Comment 3 SpanKY 2007-04-11 23:25:47 UTC]

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 ...

[Comment 4 Zac Medico 2007-04-12 04:16:39 UTC]

(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".

[Comment 5 SpanKY 2007-04-13 01:19:48 UTC]

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

[Comment 6 SpanKY 2007-04-14 16:35:58 UTC]

actually looks like Zac's latest changes addresses all issues here ... cheers

[Comment 7 Zac Medico 2007-04-16 04:21:27 UTC]

This has been released in 2.1.2.4.

[Comment 8 SpanKY 2007-04-30 20:24:53 UTC]

*** Bug 176283 has been marked as a duplicate of this bug. ***