Summary: | portage-2.0.46-r12 and higher does't remove all symlinks | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Alastair Tse (RETIRED) <liquidx> |
Component: | Unclassified | Assignee: | Nicholas Jones (RETIRED) <carpaski> |
Status: | VERIFIED FIXED | ||
Severity: | critical | CC: | mholzer, vapier, yanestra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
fixes problem with symlinks to files not being removed on unmerge
log of a merge-unmerge cycle for smpeg |
Description
Alastair Tse (RETIRED)
2003-02-09 20:36:33 UTC
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 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. |