the 'emerge clean' command removes to many when removing old libraries for which newer versions have been installed, it removes the symlinks too, which should point to the newest versions of the lib. Example: libpng.so.3.1.2.3 (the latest) has a symlink to it from libpng.so.3. But after the emerge clean the symlink dissapeard and I had to manually add it again, together with the libpng.so.3.1 symlink. So when cleanin up libs, it should not delete symlinks belonging to the lib, unless the files the symlink points at isn't there anymore. greetz Ozy
OK, I cleaned up the unmerge code to handle symlinks in this way. This will be fixed in Portage 2.0.12
Actually, this was probably caused by a bug in the libpng-1.2.1 libraries. For some reason, ldconfig thinks that they're "newer" than libpng 1.2.3 and 1.2.4. What this means is that when you merged libpng 1.2.3, the libpng.so.3 and the libpng.so.3.1 symlnk continued to point to the 1.2.1 version, so when 1.2.1 was unmerged, those symlinks disappeared. So, the libpng-1.2.3 ebuild set the symlinks correctly, but ldconfig (which gets run automatically after every merge) set them back to the way they originally were. I found this out when I totally rewrote our unmerge code only to find out that I was able to reproduce the exact same problem you described when libpng 1.2.1 got cleaned. I'm re-opening this bug and changing the title of it. We need to find a nice way to fix affected systems.
well, I have updated the libpng-1.2.3 ebuild (to -r1) to check for the existence of the libpng-so.3.1.2.1 or whatever file that is, and remove it if it exists. Tests show that it works.
I don't think it is a libpng (only) thing, because I also had to link another lib because knode broke on that one, though I cannot remember which one it was. After studying the ldd `which knode` I think it was libmng, but it could have been liblcms too, I don't know.
Seemant Kulleen wrote: > [non-member submission] > > Hi All, > > I am a developer for Gentoo Linux. We have been offering the libpng > packages for a long time now, and I am the current maintainer of the build > scripts for it. > > An issue seems to have cropped up with libpng-1.2.1 and later versions. > When libpng-1.2.1 to our user base, they had to do: > > emerge libpng > > and that installed libpng onto the system. When libpng-1.2.3 came out > (1.2.2 was way too buggy to release), many users did: > > emerge libpng > > again. After the compilation and merging into the live filesystem of all > the files, ldconfig is run. > > The weird thing is that: > /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.1 > > remained instead of updating to libpng12.so.0.1.2.3 > > This happens for libpng-1.2.4 as well. > > If they remove the older libpng-1.2.1 after emerging libpng-1.2.[34], the > symlink is a dead one. > > What gives? The makefile.linux that we supply clearly does the replacement of libpng.so.3 "emerge" isn't our product, so if it's using a different makefile than one from our distribution, all bets are off. Glenn
