I try to maintain a package: swftools. It's in the portage. During the make a symlink is created: Makefile.in: ... $(LN_S) $(pkgdatadir)/swfs/tessel_loader.swf $(pkgdatadir)/swfs/default_loader.swf ... during emerge: ln -s -f /var/tmp/portage/media-gfx/swftools-0.9.2-r1/image/usr/share/swftools/swfs/tessel_loader.swf /var/tmp/portage/media-gfx/swftools-0.9.2-r1/image/usr/share/swftools/swfs/default_loader.swf The problem is: >>> Merging media-gfx/swftools-0.9.2-r1 to / ... >>> /usr/share/swftools/swfs/default_loader.swf -> usr/share/swftools/swfs/tessel_loader.swf This installs a broken symlink. It should be /usr/share/swftools/swfs/tessel_loader.swf I made a patch to create relative symlink, and relative symlink is a better aproach and so, BUT I think this is a bug in the /usr/lib/portage/pym/portage/dbapi/vartree.py:4288 if self.settings and self.settings["D"]: if myto.startswith(self.settings["D"]): myto = myto[len(self.settings["D"]):] This cuts off the first "/". I don't know if this code works well in other cases. This problem is the same at least from sys-apps/portage-2.1.10.56 when i first noticed this. Reproducible: Always Steps to Reproduce: 1. build swftools ebuild without the relative symlink patch Actual Results: The full path symlink is broken. It has been cut too short. Expected Results: The installed symlink target to start with "/" This change fix the problem IN THIS CASE /usr/lib/portage/pym/portage/dbapi/vartree.py:4290 - myto = myto[len(self.settings["D"]):] + myto = myto[len(self.settings["D"])-1:] I'm not sure if it breaks other packages.
(In reply to comment #0) > This change fix the problem IN THIS CASE > > /usr/lib/portage/pym/portage/dbapi/vartree.py:4290 > - myto = myto[len(self.settings["D"]):] > + myto = myto[len(self.settings["D"])-1:] > > I'm not sure if it breaks other packages. Your change should work correctly for all packages. It's fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f2f4b2e3b6d7865ccef11a254055b5d213f4bac3
Your patch just fixed the merge output. It was also broken inside the movefile function here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=75d5e44211e997dbba91307f27c12f9c83579299
Sorry, my mistake. I was glad to find the code that prints the merge progress, and didn't check the real result of my fix :D So the output is calculated separated from the real file operation... This is not fortunate I think, but that's another story. Thank you!
This is fixed in 2.1.10.63 and 2.2.0_alpha108.
