Bug 470916 – sys-apps/portage-2.1.11.62: ecompressdir - inconsistent handling of symlinks

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Steven Trogdon 2013-05-21 20:25:14 UTC]

I don't believe the issue is specific to a particular ebuild but it surfaced here when building pari-2.5.4 from the sage-on-gentoo overlay. During the src_install() phase the pertinent manpages are installed via the top-level Makefile by utilizing (for amd64) Olinux-x86_64/Makefile, in particular:

install-man::
	-mkdir -p $(MANDIR)
	-$(RM) $(MANDIR)/pari.1 $(MANDIR)/gp.1 $(MANDIR)/gp-2.5.1
	$(INSTALL_DATA) ../doc/gphelp.1 $(MANDIR)
	$(INSTALL_DATA) ../doc/gp.1 $(MANDIR)/gp-2.5.1
	-$(LN) gp.1 $(MANDIR)/pari.1
	-$(LN) gp-2.5.1 $(MANDIR)/gp.1

The src_install() is basically,

src_install() {
    default
}

Relative to the portage/image folder I see on one system:

# ls -1gG usr/share/man/man1
total 12
-rw-r--r-- 1 3931 May 21 14:15 gp-2.5.1.bz2
lrwxrwxrwx 1   12 May 21 14:15 gp.1.bz2 -> gp-2.5.1.bz2
-rw-r--r-- 1 2450 May 21 14:15 gphelp.1.bz2
lrwxrwxrwx 1    8 May 21 14:15 pari.1.bz2 -> gp.1.bz2
-rw-r--r-- 1 1156 May 21 14:15 tex2mail.1.bz2

and on another

# ls -1gG usr/share/man/man1
total 12
-rw-r--r-- 1 3931 May 21 13:25 gp-2.5.1.bz2
lrwxrwxrwx 1   12 May 21 13:25 gp.1.bz2 -> gp-2.5.1.bz2
-rw-r--r-- 1 2450 May 21 13:25 gphelp.1.bz2
lrwxrwxrwx 1    4 May 21 13:25 pari.1 -> gp.1
-rw-r--r-- 1 1156 May 21 13:25 tex2mail.1.bz2

In this latter case when things are merged into the live system there is the QA Notice:

  * QA Notice: Symbolic link /usr/share/man/man1/pari.1 points
    to /usr/share/man/man1/gp.1 which does not exist.

So it appears the symlinks are being "compressed" when ecompressdir is called. But on one system a symlink to a symlink doesn't get compressed? Is some sort of a manual install required in this situation? I'm not quite sure any of the symlinks should be "compressed". I have also seen this same behavior on two, nearly identical, systems in Prefix. There are no complaints in the build.log files that anything is awry.

[Comment 1 Zac Medico 2013-05-21 20:44:29 UTC]

Currently, ecompressdir only does a single pass to fix broken symlinks. Depending on the order of traversal, this may not work correctly for multiple levels of indirection. We can solve this by looping until no more symlinks remaining to fix.

[Comment 2 Zac Medico 2013-05-21 21:41:00 UTC]

This should fix it:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c5b4a1df363a61ecb0590d64adc12e167903006

[Comment 3 Steven Trogdon 2013-05-21 22:15:26 UTC]

Yes. That did the trick. Thanks!

[Comment 4 Zac Medico 2013-05-24 05:50:28 UTC]

This is fixed in 2.1.12.2 and 2.2.0_alpha177.