i recently emerge'd and then unmerge'd smpeg, and i noticed that portage doesn't remove all the symlinks properly. specifically, it showed this while unmerging: .. <<< obj /usr/share/aclocal/smpeg.m4 --- !destn sym /usr/lib/libsmpeg.so <<< obj /usr/lib/libsmpeg.la .. <<< obj /usr/bin/glmovie <<< sym /usr/lib/libsmpeg-0.4.so.0 <<< dir /usr/share/doc/smpeg-0.4.4-r4 <<< dir /usr/include/smpeg And then I checked whether the symlink was really left behind: mcvaio ~ % file /usr/lib/libsmpeg.so /usr/lib/libsmpeg.so: broken symbolic link to libsmpeg-0.4.so.0.1.3 So I took a dive into the code and found two problems with the symlink handling. 1. when a symlink is found to be pointing to something that is still valid , it doesn't add it to "mysyms", hence does not get removed near the end. The patch attached (for portage.py) fixes this. 2. after reviewing the code, the logic suggests that portage will not remove symlink to directories properly. because it checks for broken symlinks BEFORE it removes all the directories, and doesn't do a second sweep of left over symlinks to see if they are still valid. If someone can confirm my observations, I'd be happy to make a patch for that problem as well.
Created attachment 8111 [details, diff] fixes problem with symlinks to files not being removed on unmerge this is the patch for the first problem
This is desired behavior. If a file (symlink or regular) does not match it's installed value, then it has been changed... The change is assumed to be intentional by the user or portage, and thus won't be modified. Otherwise things will break when you forceably remove their files. The second problem is not valid as they are deleted if they match.
Sorry to flog this bug more, but I think you might of missed some of my points why I think this is a bug. I'm going to attach a log of a simple merge and unmerge cycle of media-libs/smpeg so you can se exactly what I mean. Notice that the merge happens without any problems, and as you expect, it lists the real libs before the symlinks, eg: >>> /usr/lib/libsmpeg-0.4.so.0.1.3 >>> /usr/lib/libsmpeg-0.4.so.0 -> libsmpeg-0.4.so.0.1.3 >>> /usr/lib/libsmpeg.so -> libsmpeg-0.4.so.0.1.3 If it was unmerged in that order, then the problem I reported wouldn't of happened, because the obj file in this part would have been removed before the symlinks were iterated in unmerge(). But notice that in the unmerge, they are not unmerge in that particular order: .. <<< obj /usr/share/aclocal/smpeg.m4 --- !destn sym /usr/lib/libsmpeg.so <<< obj /usr/lib/libsmpeg.la <<< obj /usr/lib/libsmpeg.a <<< obj /usr/lib/libsmpeg-0.4.so.0.1.3 <<< obj /usr/include/smpeg/smpeg.h <<< obj /usr/include/smpeg/MPEGvideo.h ... Notice that because of either the sort() not working (during unmerge()) as expected, or if smpeg has a weird way of naming libs, we cannot assume that the symlinks will be iterated after their target object files. And then ultimately, I've ended up with a dangling symlink /usr/lib/libsmpeg.so: % file /usr/lib/libsmpeg.so /usr/lib/libsmpeg.so: broken symbolic link to libsmpeg-0.4.so.0.1.3 This might not be a serious critical portage bug (I mean its only a little symlink - I didn't mark it as critical :), but at least either the smpeg ebuild should be fixed so that the lib naming isn't funny enough to make portage fail removing the symlink. As for the second bug, I have yet to see an ebuild with a symlinked dir, but I could try and play around to make an ebuild that has something like that.
Created attachment 8125 [details] log of a merge-unmerge cycle for smpeg
*** Bug 16080 has been marked as a duplicate of this bug. ***
valid points imo
Comment on #c2 The problem of non-removed symlinks exists with several packages, e.g. with blackdown-jdk: /opt/blackdown-jdk-1.4.1/jre/plugin/i386/netscape7 -> mozilla /opt/blackdown-jdk-1.4.1/jre/lib/i386/server/libjsig.so -> ../libjsig.so As you can clearly see, the referenced files are part of the package; so while they are removed, their references are not. This I'd consider a bug.
2.0.47-r2 is stable now
true, can you guys verify that this still happens with 2.0.47-r2 ?
Yes, same problem with 2.0.47-r2 (see PR 16080).
Yes, this still happens with portage-2.0.47-r2: # emerge unmerge smpeg media-libs/smpeg selected: 0.4.4-r4 protected: none omitted: none [...] <<< obj /usr/share/doc/smpeg-0.4.4-r4/CHANGES.gz <<< obj /usr/share/aclocal/smpeg.m4 --- !destn sym /usr/lib/libsmpeg.so <<< obj /usr/lib/libsmpeg.la <<< obj /usr/lib/libsmpeg.a <<< obj /usr/lib/libsmpeg-0.4.so.0.1.3 [...] <<< obj /usr/bin/glmovie <<< sym /usr/lib/libsmpeg-0.4.so.0 <<< dir /usr/share/doc/smpeg-0.4.4-r4 <<< dir /usr/include/smpeg [...] # file /usr/lib/libsmpeg.so /usr/lib/libsmpeg.so: broken symbolic link to libsmpeg-0.4.so.0.1.3 # emerge info Portage 2.0.47-r2 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r3) ================================================================= System uname: 2.4.19-gentoo-r10 i686 Celeron (Mendocino)
fixed in cvs for -r3
out shortly
i can verify that portage-2.0.47-r3 removes symlinks correctly. thanks!
Sorry, I still have got a problem. portage-2.0.47-r4 still fails to un-install a package completely. If that corresponds to the symlink problem, I can't say. # emerge blackdown-jdk ... # emerge --unmerge blackdown-jdk ... --- !empty dir /opt/blackdown-jdk-1.4.1/jre/plugin/i386 --- !empty dir /opt/blackdown-jdk-1.4.1/jre/plugin --- !empty dir /opt/blackdown-jdk-1.4.1/jre --- !empty dir /opt/blackdown-jdk-1.4.1 --- !empty dir /opt --- !empty dir /etc >>> Regenerating /etc/ld.so.cache... * GNU info directory index is up-to-date. # ls -lR /opt/blackdown-jdk-1.4.1/ /opt/blackdown-jdk-1.4.1/: total 1 drwxr-xr-x 3 root root 72 Feb 26 22:54 jre /opt/blackdown-jdk-1.4.1/jre: total 1 drwxr-xr-x 3 root root 72 Feb 26 22:53 plugin /opt/blackdown-jdk-1.4.1/jre/plugin: total 1 drwxr-xr-x 2 root root 48 Feb 26 22:54 i386 /opt/blackdown-jdk-1.4.1/jre/plugin/i386: total 0
I committed comment #16 as Bug #16460.
